Memory safety prevents 3 vulnerabilities that lead to remote code executions, not "most" or "all" of them. They're 3 very common and important vulnerabilities, though.
It's a bit tautological to suggest that fixing the most common RCE flaws in C/C++ programs by replacing the language is the same as fixing all of the most common RCE flaws. The clear point here is that memory corruption is an affliction of C/C++ programs, but that other languages have other RCE-breeding flaws.
The C/C++ RCE bugs are buffer overflow (heap, stack, heap/stack via integers, &c), UAF (and double free), and uninitialized variables. It looks like there's a whole menagerie of different C/C++ RCE flaws, but they really just boil down to bounds checking, memory lifecycle, and initialization.
Metacharacter bugs apply to all languages, but since Rust doesn't eliminate them --- virtually nothing does, with the possible exception of very rigorous type system programming in languages like Haskell --- the metacharacter bugs rebut the parent commenter's point.
Eval() is an RCE unique to high-level dynamic languages. Taxonomically, you'd put serialization bugs here too (even the trickiest, like the Ruby Yaml thing, boil down to exposing an eval-like feature), along with the class of bugs best illustrated by PHP's RFI ("inject a reference to and sometimes upload a malicious library, then have it evaluated").
Those are just two bug metaclasses, but they describe a zillion different RCE bugs, and most of them are bugs that are not routinely discovered in C/C++ code.
If you remove custom software like Intranet apps and focus more on products that have near ubiquitous deployment (like common desktop programs, OSes, basic server-level code), how do you think the come out? What about by number of people impacted?
Right. There's an infinite number of vulnerabilities; fixing any finite number of them still leaves you with almost all vulnerabilities outstanding. But still, fixing them is good.
