Bloat mostly reflects Conway's law, with the outcome of it being that you're building towards the people you're talking to.

If you build towards everyone, you end up with a large standard like Unicode or IEEE 754. You don't need everything those standards have for your own messages or computations, sometimes you find them counter to your goal in fact, and they end up wasting transistors, but they are convenient enough to be useful defaults, convenient enough to store data that is going to be reused for something else later, and therefore they are ubiquitous in modern computing machines.

And when you have the specific computation in mind - an application like plotting pixels or ballistic trajectories - you can optimize the heck out of it and use exactly the format and features needed and get tight code and tight hardware.

But when you're in the "muddled middle" of trying to model information and maybe it uses some standard stuff but your system is doing something else with it and the business requirements are changing and the standards are changing too and you want it to scale, then you end up with bloat. Trying to be flexible and break up the system into modular bits doesn't really stave this off so much as it creates a Whack-a-Mole of displaced complexity. Trying to use the latest tools and languages and frameworks doesn't solve this either, except where they drag you into a standard that can successfully accommodate the problem. Many languages find their industry adoption case when a "really good library" comes out for it, and that's a kind of informal standardizing.

When you have a bloat problem, try to make a gigantic table of possibilities and accept that it's gonna take a while to fill it in. Sometimes along the way you can discover what you don't need and make it smaller, but it's a code/docs maturity thing. You don't know without the experience.