See ShellShock. Having memory safety vulnerabilities doesn't prevent other bugs. C and C++ projects still have logic errors, broken auth, XSS, SQL injection, and do dangerously dumb stuff, and that's on top of buffer overflows, user-after-frees, data races, and UB footguns.

Nobody promises that memory safety will fix all bugs, but it can prevent or significantly reduce a class of vulnerabilities, and reduce the total number of serious defects. And then time and effort saved on dealing with memory corruption bugs can be redirected towards dealing with all the other higher-level issues.

> Projects that use C the easy way have much better safety.

That's just another way of blaming programmers for not writing C without the bugs.

Every language can be perfectly safe if used correctly — even hand-written machine code. The problem is that it's easy to say "use C the easy way" (whatever that means), but actual real-world uses don't live up to such standard, and even the best programmers can make mistakes. Language safety is about making programs safer even when programmers write less-than-ideal code.

You're talking about using C the hard way, that's difficult to get right indeed, because it's the hard way.