I’ve spent a non-trivial portion of my career hunting down and fixing memory corruption issues, …

I think this comes from people trying to use rust to replace fast gc languages (e.g. C#/java). rust is much lower cognitive overhead than writing correct C/C++, but it's a lot harder than writing code where memory is automagically dealt with for you.

Because for most software 'good enough' is the best outcome. Users don't care if you wrote it in Rust (unless the target audience is developers). All they care about is if it solves their actual problem: a real world, pain-in-the-neck problem. If you take 20% longer to write it in Rust, that's short term cost for long term gain, but users don't think that way. Everyone from the users, sales, marketing, product and even engineering departments want the product out the door yesterday, so the pressure is always on. Users don't care if you need 30% fewer CI servers. The CEO doesn't care if one additional dev has to spend his time making sure asan, ubsan, etc are running properly. This is cost factored into pricing. Coverage metrics are used as proxy metrics for quality. Meanwhile the devs are wrangling the complexity of the software itself, which requires mental resources. Any additional com…

Because the language's resource allocation style is not so much a "cross-cutting concern" as something which is all-pervasive across every single non-trivial program written in that language. For a long time, we had four styles: Static allocation, purely manual management of dynamic resources, garbage collection (usually with manual management of some resources), and "don't worry about it" for truly high-level declarative languages. RAII adds something to this, but C++ didn't give up new and delete (or malloc and free... or anything whatsoever) so it isn't really a wholly new paradigm. Rust, however, adds something that's genuinely new to most programmers, and it requires a re-working of the thought-styles, so it's worth thinking about whether it's worth it.

TCO is not that important in most cases compared to finding out what to build and estabilishing the user base and not failing due to slow iteration speeds at the beginning. If it takes off, the value derived from the software is tends to be more than the cost, so discovering more things to build is better than optimizing sw expenses at second half of the lifecycle. Of course there are exceptions, sometimes the potential upside delivered by the software is small and capped and the requirements fixed in advance, and implementation path is well trodden...

I am still in awe that I could write an entire emulator in Rust without encountering heap corruption, use-after-frees or segfaults in host code (as opposed to guest code, the code under emulation). It's a truly amazing language.