Some types of software require memory safety models that Rust was not designed to express e.g. safety models when mutability of references and ownership of objects are not observable at compile-time. High-performance database engines tend to have this challenge due to pervasive DMA-ed I/O and opaque page-structured memory. The OS hides this from most applications that aren't high-performance systems code. In C++ (which also looks askance at these memory models) this is addressed by designing an execution scheduler to dynamically guarantee safety; the scheduler understands the memory model and never schedules or executes a sequence of concurrent operations across a set of mutable references that would violate the safety model -- the operations are oblivious. In modern designs this requires no locks and negligible state.

Rust can deal with these types of memory models too while minimizing the amount of unsafe code with enough layers of indirection, it just has a high performance cost.

I don't see how this generalization follows from the three examples you've cited?

Rust in production use tends to be found in circumstances where there is no need for mature tooling, and no expectation of a need to hire experienced coders. Of course there are exceptions.

The tooling does need to be more mature but for many projects the pioneer tax paid to improve the tooling may be worth it. Besides, it's not as if C++ dependency management is very mature either — most people build custom tooling for that anyway.

Go is not in the same performance category as Rust and C++. It has more limited use cases where it works well, due to mandatory runtime. Rust and C++ are more general purpose.