At least in my piece of corporate software engineering, I'm looking at Rust as a "gateway drug" for FP. Management doesn't want to take the risk of investing in FP, so reliable choices like Java and C++ are usually endorsed; the safety aspects of Rust are a much stronger argument for them.
I don't think the safety aspects are a much stronger argument. Managed languages like Java and C# are safe. The garbage collector isn't going to let you ++ your way into remote code execution and most corporate software engineering isn't heavily concurrent. I think a stronger argument would be to advocate for a more functional language on the same runtime, like Scala or F#.
Java and C# will not provide any sanity check on your use of locks and shared mutable state though. But the Rust borrow checker will. It won't prevent deadlock or race conditions, but it will at least guide you there much better than those pass-by-mutable-reference OO languages will.
99.9% of all code written in these languages uses a thread per request model. Objects never go over a thread boundary. Using rust will only complicate these code bases for concerns that will never occur.
…and if you’re concerned about mutability you can use an immutable first language like Scala or F#.
I guess I would even say it's like... most people just want the banana, but got a gorilla holding the banana and the rest of the jungle as well.