I'm not sure why you say this. Go look over Microsoft's CVEs for the past two years. I did, and, apart from the CLR-in-a-browser scenario, nearly every single critical CVE was a direct result of memory safety.
In other words, if we magically went back in time and wrote all MS products in Rust instead of C++, their CVE could for RCEs, their famous worms, etc. would all disappear (except in the cases where they explicitly opted into unsafe features.)
Those worms would disappear but you can't say for sure that the crackers just wouldn't find other vulnerabilities to focus their efforts on exploiting. That is to say, having gone through the cracking process myself (for research purposes, of course!), you find the lowest hanging fruit you can find, and once that fruit is gone you move on to the next lowest fruit.
Back in the 90s and early 00s, a lot of the low fruit was buffer overflows or forged pointers. Then we got serious about fuzz testing and static analysis, and now they are picking at other fruit (which is why Heartbleed was so weird).
OK then look at the CVEs for the last couple years. The reward for finding a 0day RCE in a MS product is so high, I don't think it's accurate to say it's just the low hanging fruit.
In other words, if we magically went back in time and wrote all MS products in Rust instead of C++, their CVE could for RCEs, their famous worms, etc. would all disappear (except in the cases where they explicitly opted into unsafe features.)