It isn't new, but it's in the buzz. Let's face it, stateless MVC for the web is a local maximum. We can do much better, but not if we stick with this MVC crap.
MVC seems an odd paradigm for the non-realtime web, when you have to instantiate every object on each request, and data update events are the exception, rather than the rule.
For simple cases, I often fall into a (M/C)+(VL/V) pattern: model and controller fused into one layer, view-logic and view into another. If database logic is sufficient complex or used in multiple places, break it out into its own layer, same for view logic. No pattern can or should be a universal panacea for every use case.
All that said, I'm really liking Laravel's approach. It's high time that PHP frameworks started getting wise to closures.
> when you have to instantiate every object on each request,
The thing about this that it lends itself well to HTTP because HTTP is a request-based system.
Once you start breaking down the barriers between requests you get all kinds of horrendous issues with race conditions and memory sharing and pain. Sessions just about get by this because they are per-user and people don't oft do huge amounts of things concurrently.