All frameworks set out to be simple, clean, and fast implementations of something more established but they lack more fancy bells and whistles. Then as they catch up in features, they became the same complex beasts and the cycle repeats.
Do you have specific ideas (or concerns) about how Bevy is architected (or how it adds new features)? We're doing our best to avoid this fate.
Tiny glade is a game that uses bevy_ecs, but doesn't use bevy's rendering crates at all. Personally I have several WIP PRs that implement alternative rendering paths (raytracing, GPU-driven meshlet + visibility buffer rendering) and nothing internal to Bevy really changes. For users, again nothing really changes, they just add a FeatureFooPlugin to their app and then use FooComponent or whatever and it all works.
While individual crates/plugins might get bloated, Bevy as a whole will be fine. Users can choose to ignore those plugins, and use something else that works better for them.
I would also like to point out that this is a game engine - by definition, they're bloated and complex beasts, and absorb every feature under the sun because _someone_ will have a use case for some kind of game. The key is how the feature bloat affects ergonomics. It's totally fine to have 1000 features, as long as you don't _need_ to interact with most of them unless you want to.
The nice thing too is with cargo, should you ever commit to bevy, they can break the future, and you don't have to chase a moving target. You can just stick to your version. But they also provide guides to make moving up to the latest and greatest easy. Or at least that's been my experience as a bevy dabbler.