I think you managed to put the question regarding the bloat problem very nicely - and came with an counter-example which is very good.

Bloat in this context is the size of overhead - usually for lack of finer grained choices. And from what I saw so far in the wild, the choice among the dependencies comes from cherry picks: people need few features of the whole Doctrine set - there is a limit of how less one can import into your dependency tree; one will import more than actually needed.

Because one is importing more than needed, one might incur in several sets of problems: security (in which the module has a flaw in a far distant point, nothing related with what is actually being used - but then you need to be very knowledgeable about the internals to make decision on whether upgrade must take place or not), lack of ability to restrict the interface or execution path of your code (in JPL C++ projects for instance, their manual commands you to use only a subset of C++ features so their statical analysis tool actually works), huge untouchable spots of optimization/refactor (usually you can optimize/refactor your code, the code around the dependency - but the dependency itself, no) among few others.

The problem with bloat - in PHP ecosystem essentially almost all useful libraries/frameworks - is that you don't actually know what you are importing into your project; it could make it faster, lighter and shorter - but also, slower, heavier and longer.

But even that, I would not be complaining if PHP did not have batteries included. Alas, PHP has it!

E.g., you wanted a better interface to $argv. The low overhead solution is own PHP getopt; but people jump straight to Symfony Console - which is, I must add, an amazing piece of code; If people wanted a cradle to run their CLI application including builtin shell system, then Symfony Console offers proportionally low overhead of execution and implementation.

E.g., you wanted to run a process. The low overhead solution is using exec and escapeshellarg. What people do? Jump to Symfony Process - which is, I must add, another amazing piece of code; If people wanted to run their processes with output parsing and controlled timeout, then Symfony Process offers proportionally low overhead.

And everyone seems fine with it - always answering developer time costs more and infrastructure architecture would solve of the potential downside of having these large chunks of overhead.

These assertions are highly debatable truisms - skilled developer time costs a lot always. If you have in your code Symfony/Laravel/CakePHP etc, you are restricting your pool of available skilled workers to only those who actually know Symfony/Laravel/CakePHP. But we all know that these are not the only choices we make, just look into composer.json: you can have weird combination of Laravel/Twig/Doctrine/Symfony Process etc etc etc. So find a developer that know how to use this plethora of choices will always cost a lot. There are millions of PHP developers, PHP developers who master at the same time some Symfony Component/Laravel/Doctrine and whole truck of dependencies are fewer -- all of this caused by importing bloat or letting the base code getting bloated, ie, a huge overhead both in knowledge as much as in execution time by the combinatorial explosion among the dependencies.

And infrastructure architecture is limited by the application itself: if the application is not malleable to accept more hardware to solve its needs; you can go nowhere. You can perfectly make an application using all nice libraries and frameworks, and still not be able to throw more hardware into the problem.