And frameworks are, by definition, bloated.
Most are bloated, but some are not. When I was doing Assembly on the 6809 in the 1980s, I wrote a framework that contained everything I used in most of my programs (printing to the screen, letting the user input a line of text, printing to the dot-matrix printer, modem file transfers, saving and loading files, etc). My assembled projects were quite small (usually around 20-25 kilobytes when finished). I did not include anything just for the hell of it, and my framework saved me tons of time on subsequent projects.
Fast forward to about 12 years ago, when I started creating a Web programming framework for my own use. The framework is about 50K lines of PHP code (including comments and whitespace). It does include some dead code bloat, as it originated from a project I was writing for a specific project (which is easily trimmable if I ever get around to it). Barring that project-specific code, though, I would have to rewrite the vast majority of the framework for each Web project, so it is actually rather trim around the waist. It easily saves me years-worth of man hours on each project, and each project uses about 95% of the framework.
But most modern frameworks are indeed bloated all to hell with no justifiable reason. And the reason is probably because they want to do everything for everyone, which always results in a bloated pig. But frameworks that target a specific need can be lean and efficient.