Do you have a source for that claim?
The problem with these tools are that the instrumentation code inserted by the compiler comes with a 50-100% program-wide performance loss (*) and that's not acceptable to C++ developers. So in practice, you don't just add -fsanitize=address to your builds, you add it to test builds and fuzz them. But now you're not just trusting your compiler, you're trusting your tests and coverage.
The promise of Rust is that many of the memory safety bugs are forbidden at compile time in safe code, and the stuff that has to be checked at runtime (self referential data structures, out of bounds, etc) is able to be added more granularly with unsafe opt-outs where appropriate which means that you're not going to pay 50-100% in raw performance.
* take this like all perf numbers with a heap of salt, do your own benchmarks and come to your own conclusions.
I have always enabled bounds checking, and never ever, did it matter for the kind of projects I was involved with.
Not everyone is really writing a VR engine for a console rendering at 120 FPS, but just like everyone wants to be Google, so do much of those developers.
If you care about safety use gsl::span instead.
https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf https://clang.llvm.org/docs/AddressSanitizer.html
In many cases we already have the tools. The problem is that people are not using them.
That said it is still in general a good thing to steer people away from C / C++ due to the languanges being very hard to use correctly.