> Accepting that it is extremely difficult to achieve complete memory safety with the performance level suitable for production deployment

I don't think this is true anymore even for system code. As Rust demonstrates, fat pointers and apropriate compile time restrictions ensure memory and type safety with marginal performance overhead.

It's simply not a problem to bother with anymore in the 21st century, if not for the immense legacy of unsafe C/C++ code and the inertia of the industry and people.

I would not say this is a solved problem - Rust is too young in the industry; let's wait and see. Java claimed it solved all memory-related issues, and some even stated good security because the programs were executed in VM. Many years later, we saw you could make memory leaks in Java, and you can escape VM.

There is no inertia here but an expected outcome. C/C++ programs are often predictable, memory issues are easy to catch, and tooling is top-notch. Good luck with other languages, except maybe with JVM/.NET platforms.

Not to mention binary size too.

The same program written in Rust can be magnitudes larger in binary size[1], which is a complete non-starter for many embedded projects (where a lot of C/C++ code is destined to live).

[1] https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna