I think multiplayer is an area where you'd want "fearless concurrency". Rust could do well here.
A better argument might be Rust and Vulcan, though. Even still, you can get very far with just using OpenGL.
Is that it doesn't benefit, or is it that the benefits are too hard to achieve given the nature of memory issues with games that like to have global state and are written in C++? A lot of games do a bunch of things every frame and then increment state. Those can all be parallelized as they only depend on the previous frame's state.
You can't just take any type of game logic and parallelize it either, since there are types of game logic that aren't just dependent on the previous frame. You may be wholly dependent on something that has just occurred earlier in the frame, but has not been networked to clients yet.
Not to be condecending, but you should try making a game and see how well that parallelization idea of yours turns out.
So, the phrase "a tremendous amount of game code doesn't benefit from multithreading" is actually true since most game code is in unreal/unity, but it's not a hard constraint for all game engines.
The problem is that most naive "game engines" which provide nothing more than bindings to OpenGL/bgfx, OpenAL, Box2D, etc. and are really just "game libraries," don't even provide things like out-of-the-box multiplayer or level loading, so the idea that they're going to make the leap from providing basically nothing to providing mechanisms for multithreaded game logic, which requires some sort of gamerules/gamemode abstraction first is not something I think you'll see in practice.
Most game libraries or game frameworks like these only provide things like load, update, draw callbacks with some nice bindings.