"I feel like people who criticize framework A or B try too hard to over-architect their applications and go out of their way to avoid using the framework - defeating the purpose of using a framework...
When building a web application, you have three choices:
Build everything yourself from scratch and have "perfect" architecture built precisely to your own standards.
Use a framework, build what you need quickly, and live with the fact that your application and your framework are attached at the hip.
Use a framework, and try like hell to keep the framework away from your "application" code, writing dozens or hundreds of boundary adapters, wrappers, and interfaces, plugging all leaky abstractions etc.
All of these have advantages and disadvantages.
#1 makes you an unproductive code hipster
#2 means you'll build what you need quickly, but you're now stuck with with your framework. If you don't plan on changing frameworks, great, no major problem. Just don't make your shit untestable - but that's on you, not the framework.
#3 means you're basically not using the framework to your advantage, because you're writing a shitload of insulation code (adapters, interfaces, POPOs) and using a framework.... by not using a framework???
What I've found is that rarely does "leaky framework" usage cause problems, unless you like porting your application between different frameworks for some reason. What slows you down is your own code architecture:
Inappropriately applied abstraction
Poorly designed cohesion
Loosely and tightly coupling the wrong things
Poorly defined responsibilities
Not once have I ever said "shit, I wish I didn't use Eloquent here" or "Man, that request facade is really biting me in the ass" or "Crap, the router has too many methods".
What I have said is: "shit, I tried to solve two similar but different business rules with the same method, and now they're tightly coupled together, and separating them out is going to be a pain in the ass".