A sibling comment suggests this has more to do with where you work than how modern your C++ is, which rings true to me. Different kinds of programs need different kinds of memory management patterns, and some are more error-prone than others.
In my experience there also tends to be a long tail of memory corruption bugs. After flushing out those that are easy to run into or that have a major impact, everything seems fine and you can go years without really spending time on them, but they're still lurking at the edges of automated crash reports and mysterious bug reports you never quite manage to reproduce yourself. And when I do manage to track one down, it's as likely as not to be in, around, or even caused by modern C++ features.
Tetris puzzle or not, it's really quite nice to systematically rule out those kinds of issues. In some domains it may not be worth it, but in others they can hide major security issues or similar. And either way it sure beats periodically digging through crash dumps trying to piece together something that looks impossible from the surrounding source code.
If you need extreme robustness you have to have coverage and fuzzing and canaries and stuff for logic bugs as well as memory bugs. If you’ve got a long tail of non-exercised code paths, a “<“ flipped with a “>” will fuck up your day just as bad as a use-after-free.
If your code is covered, ASAN will red-zone the memory bug. It checks every address.
People are welcome to their subjective opinions about the “easiest” way to get truly correct software (which almost no one needs), but the oft-repeated assertion/implication that the tools don’t exist to do it outside of Rust/Go is wrong. Not a subjective opinion, demonstrably incorrect.
And when enough truly important shit is written in Rust, which will be soon, there will be CVEs. Many of them.
Well, yeah, if you're reaching for that level of robustness you want every tool you can get. If you can get rid of a whole category of bugs with one tool, that only makes the other tools more effective for the rest!
(There are also cases where that extra robustness is more of a "nice to have," so if you can get a side effect of your approach to something more important, that changes the calculus too.)
In my experience there also tends to be a long tail of memory corruption bugs. After flushing out those that are easy to run into or that have a major impact, everything seems fine and you can go years without really spending time on them, but they're still lurking at the edges of automated crash reports and mysterious bug reports you never quite manage to reproduce yourself. And when I do manage to track one down, it's as likely as not to be in, around, or even caused by modern C++ features.
Tetris puzzle or not, it's really quite nice to systematically rule out those kinds of issues. In some domains it may not be worth it, but in others they can hide major security issues or similar. And either way it sure beats periodically digging through crash dumps trying to piece together something that looks impossible from the surrounding source code.