The biggest benifit to something like Laravel is that a new developer to your team can step in and know where everything should be and how it should generally work without asking. There is good documentation so you dont have to write that for your foundational code, just your business logic.
A bunch of bespoke packages strung together with no logic does not provide that. You can surely look up how one package works but its a lot harder to figure out how it all ties together.
I can see how it's seen as a benefit, but the flipside is that you're teaching your developers Laravel, not PHP. They assume whatever they do, they do in a good way because it's Laravel that does it which is great, but it abstracts actual knowledge. It's like if a developer uses SQL exclusively through an ORM and DBAL, how much can they be expected to know about the workings of SQL performance, indexes, etc.
I also find it very interesting that there's no stigma associated with "Laravel developers" that focus exclusively on that framework and its syntax and way of doing things and you have "WordPress developers" who do the exact same but are seen as incompetent.
I understand though that there are scenarios in which what you want is a guy that knows a framework really well, but if we're talking about skills of a developer, I'll pick the guy that knows vanilla PHP over a framework specialist 80% of the time
I find it hard to imagine how anyone who groks Laravel well enough to get a product shipped could be deficient in understanding PHP. Surely such cases are outliers?
I regularly interview PHP developers for hiring and I can quickly classify them into 1. Wordpress Developers, 2. PHP developers and lately 3. Laravel developers.
Specifically for no 3 is the kind of developer who considers the framework magical and has no idea how things are done without it because they've learned framework first and the PHP basics to survive. They can do well for basic CRUD tasks but for anything trickier they get stuck.
Being Laravel focused and knowing what is happening underneath the hood are not mutually exclusive. A mature developer knows when to stray from the framework when its absolutely needed, not when it just seems like a fun thing to do. 99% of the time the frameworks predetermined path is the right way as its the simplest to maintain.
A bunch of bespoke packages strung together with no logic does not provide that. You can surely look up how one package works but its a lot harder to figure out how it all ties together.