I understand what you're saying, but I'm not sure I agree.
For example, look at Google Chrome. They've got mountains of cash. They've got loads of people working for them, and loads of job applicants if they want more. They've got a strong business case to work on security. They've got in-house pen testers, and a bug bounty program. They've got code reviews. They can afford any static analyser on the market. They've got sandboxing. They've got open source so many eyes can spot bugs easily. They can dictate terms on requirements - if Chrome vetos a new web standard and it's as good as dead, and if Google decides plugins have got to go, they go.
And they've got 177 CVEs so far in 2021 [1] - including such greatest hits as use-after-free, buffer overflows and out-of-bounds access.
You and I think we're writing secure C++ - but if the best-resourced team in the world can't write secure C++, isn't it more likely we're just fooling ourselves?
The point is that memory safety bugs are the gift that keeps on giving.
You can throw as much money into the problem as you want, and the inherent complexity of memory management means you are still gonna ship bugs of all severity.
I might be wrong about this, too, but I think a lot of smaller companies have the really bad practices. Google shines as one of the major "suppliers" of C++ tooling, and their code quality is undeniably very high (considering the complexity of some of their codebases), but a lot of popular libraries are written by small teams, often not even under contract, and you end up with a lot of PR'ed stuff, which is great, but it needs to be thoroughly reviewed.
A good example of "unqualified" PR's was that recent one with the malicious PR into the linux kernel by some university. It was caught, but it does make you wonder how many vulnerabilities make it through because of simply trusting "random unqualified people" too much.
That's needless extremism, moderate programmers benefit from safety mechanisms, and you can't hire a lot of perfect programmers.
Instead, people should be schooled to write better code. Thats it. Don't let some random new employee with no certifications write safety-critical code. Don't hire people who are under qualified. Its really that easy.
I have no idea, honestly, how you would introduce a use-after-free bug with C++'s smart pointers. Its the lack of schooling, the lack of certification, and the lack of a safety-focused selection of applicants, not a language that you can write bad code in if you ignore all warnings and advice.
Even rust has unsafe{}, but I dont see anyone complain when thats used to introduce safety issues, because "youre not supposed to do that, even though technically you could".
You can have all the safety mechanisms in a language, but you need control, too, and anyone who is completely unqualified will use that to break something.