Laravel does this very well, not just by being a great framework but also in its ecosystem (Envoyer, Forge, Spark, Nova, Horizon, Socialite) and its documentation (https://laravel.com/docs/master).
I understand that PHP developers love it. It's orders of magnitude better than doing everything by hand. But no, thanks.
Compared to Django and Rails, Laravel has those two problems I said. I don't think I ever saw a benefit of Laravel compared to them, except for the easy to deployment of PHP (that is a mixed bag anyway).
The ASP.Net and Java frameworks are so different that any comparison could join Django, Rails, and Laravel as a single point. Everything on those languages is more bureaucratic and stable, easier to compose more complex projects, but harder to create simpler ones.
Compared to snap (I've used very little of Yesod, but looks like it's alike here), the trio Laravel, Django, and Rails compose pages much better (it's a shame really since "compose" and FP go hand to hand, and I expect that to change in the future), but the FP frameworks are much better for creating data services.
Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.
Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code.
One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files.
That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).
The problem is that it gets taken to extremes when it's done at the framework level.
The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around.
Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful.
If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting.
IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem.
The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC.
Within modules usual namespacing and new constructors were used liberally.
Still over-engineered I guess but sometimes it means you won't have to go against the framework for some complicated tasks.