This aside: if we assume the speed gains in future computing will be more about number of cores than CPU frequency then using a language which has some guarantees around concurrent code and data races is probably not a bad idea. It is really quite easy to shoot yourself into the foot when you run parallel code in traditional systems programming languages.
Someone liked the idea of writing a game engine in Rust and so they did. I wrote my own sidescroller engine when I was 16 as well, although there were existing things around and it thought me a great deal about how to tackle multiple classes of problems.
Now the bevy devs seem way more experienced and if there was already a game engine that ticked all their boxes they might not have started developing a new one. But the point here is: Not everything is a product with an clearcut target audience — and not everything has to be.
Projects like these ultimately help the whole field of game engines to move on and innovate.
Right now, the team who is seeing the most success with Bevy are actually building CAD software! They needed something powerful, fast, incredibly flexible with "game-like" functionality.
That said, from talking to the hobbyists in the community, they like Bevy because it's:
- code-first
- written in Rust (C# is fine, but Unity's C# is something of a DSL, and game engine C++ is really rough)
- cares about good documentation and a helpful learning experience
- supports them in contributing fixes to issues they run into
- is incredibly flexible: you can just swap in your own physics or rendering to realize that weird idea you had, or just for the learning experience
Unity in particular was a meme for the last generation due to CPU-based stuttering.