C++ programs tend to be heavily inheritance oriented, with huge lists of includes and inheritance. Decoupling things to parallelize them is very difficult in that environment. Rust is mostly a single assignment language with move semantics, which encourages creating objects (yeah, the Rust crowd calls them structs) and passing them off to something else in a somewhat functional style. So you get programs that are less tightly coupled. That's useful if you find you want to pass an object to another thread, put it on a queue, etc. for performance reasons.
Any dangling pointers or cross-thread references will be caught at compile time. That alone makes development far easier.
So it is always a matter of equating the value of a full rewrite and how well the checkers are able to provide valuable feedback.
Which I concede Rust will be much better, however then there is the whole loss of ecosystem to also consider.
> Which I concede Rust will be much better,
Aren't these two statements contradicting each other?
Games also really don't care since they are single use applications. You are not going to run something else cpu intensive in the background while playing.
99,9% of games that you describe are built in C++, it works fine. Modern engines are doing that without much troubles.