It really comes down to if we are approaching an engine's viability from a lens of a techie who wants to push the limits of the industry, or as a entrepreneur who wants a tool that fits their workflow. I'm a bit in the former, but those latter games do help get funding for projects so the engine can push further.
However it isn't on the same league as the studios that care about shipping games in C, C++ and Assembly as main development tools.
Right now, other than Bevy existing efforts, and absent of regulations that force those studios to adopt Rust, there aren't many reasons on the market for those studios to change their tooling.
As small history lesson, it was the success of games like Quake that finally settled using C and C++ for game development, after they started to enjoy some love in the demoscene.
C on game consoles, followed by C++, only started to be a thing after the PlayStation, the first games console to ship a C SDK instead of having only Assembly based tooling. Also Yaroze only had C support.
C++ joined the party via the PlayStation 2 SDK.
C# was used for the first time successfuly on Arena Wars[0] back in 2004, with the studio doing their own OpenGL bindings.
It took Managed DirectX, followed by XNA and XBox Creative Arcade, MonoGame, Unity adopting MonoGame for their crossplatform rewrite (they were originally Mac OS only), lots of money to bring it to game consoles, for .NET based tooling for finally starting to be relevant as well.
Before Unity took over, it was already being used as alternative to create game tooling based on C++ and MFC.
Java never had much luck, because Sun understood game development even worse than desktop development, so the JavaGamming initiative went nowhere, even though there were nice engines like jMonkeyEngine, JOGL and LWGL.
There was LibGDX for a while, but the RoboVM acquisition from Xamarin, only to be shortly acquired by Microsoft thereafter, kind of killed what it had going for it.
Still, it is unavoidable on Minecraft, where Bedrock version isn't nowhere the mod community size as the Java one, and Android casual games. Also Android non-casual games do require some level of Java/Kotlin code, given that only rendering and audio is exposed on the NDK.
Note that despite all the Rust adoption talk by Android team, there are no plans for official Rust support on the Android NDK, and Kotlin Native might even get there first, still looking forward when this might change.
For those that do care: Rust for those studios won't be adopted as abruptly "we're using Bevy now!". Studios will probably start slowly tooling parts of Rust in more critical parts of the engine, or using frameworks made over the coming years. Most engineers not dedicated to that work may ever even know there's Rust under the hood.
-----
I guess my main reservation comes from me looking from a different lens. It won't be Naughty Dog nor IDTech that will make the "Quake" of Rust, it'll definitely a small, lean team closer to that of Croteam, or at least a yet unknown studio with that kind of discipline for optimization built into their culture. And with the current landscape it's not going to be trying to fight with AAA games to achieve that milestone. But it'll build it's own community around it and overall rise all ships from that. How high it goes from there, I can't say.
----
P.s. I do appreciate the history lesson. Also reminds me how I'm a bit sad that Microsoft killed so much of the potential C# scene last decade. C# always felt like a good middle ground between the nwas that was Java for Game Development while still staying in a safer space for those who don't need blazing fast C++ support. At least they still supported C# itself to a point where we almost have all the tools needed to work a basically unmanaged environment when needed.
