And be sure you don't cite reasons why you need unsafe callouts to unsafe capabilities. Nobody denies that.
Explain why you need a language that is pervasively unsafe, unsafe by default. Explain to me what code you are writing that has to routinely access memory outside of arrays. Explain to me what code you are writing that simply must be able to use pointers to access memory in unsafe ways.
In a nutshell, explain what these amazing benefits are to memory-unsafe languages that somehow offset the many and manifold costs we've found over years of usage.
Memory safety in a modern language is not only virtually free, it's a positive benefit. I simple do not see an argument for memory unsafe languages, especially given that every single one of them ship with "unsafe" capabilities available on demand and fully documented.
(Also recall "memory safe" does not imply Rust. Rust is a particularly strong language on that front, sure, but memory safety is basically every currently-used language except C and C++. People advocating for memory safety are not advocating for everything to be moved to Haskell or Rust.)
So why? Why should we keep using memory unsafe languages? It's all cost and no benefit. Who wants that?
(The only practical answer is "I've got a system here written in C/C++", and I concede the engineering pressures that can keep you there. But my personal opinion at this point is that greenfielding a project in C or C++ without adjoining a strong code analysis on day one is rapidly approaching, if not already reaching, professional negligence. And I've got my stink eye on C or C++ with strong code analysis.)