Having said that, though, Laravel is relatively unusual among major frameworks in that it doesn't seem to have been developed in tandem with a real-world project like Rails and Django were (e.g., BaseCamp and the Lawrence World Journal's internal CMS), but rather developed just to be "a better framework." Each successive release of Laravel seems to push even harder at tying you up with other Laravel add-ons, some of which are paid services. Rails and Django are open-source projects, but Laravel is an open-source product. Again, not necessarily bad, but there's an increasing feeling that the Laravel commercialization model is "give us sufficient money and you'll barely have to write any code."
My other nitpick with Laravel is that learning to develop with it is often learning to develop specifically for Laravel rather than learning to develop for PHP. This is a charge leveled against Rails and Django, too, but Python and (perhaps especially) Ruby are just better languages for developing DSLs in. Laravel has to jump through a lot of hoops behind the scenes to do what it does, leaving you with a framework that isn't particularly nimble and design patterns that often aren't particularly applicable to the rest of the PHP world.
If you're willing to hop fully on board with the Laravel train, none of this may be an issue for you. But at this point I'm not convinced that smaller PHP projects, at least, might not be better off without frameworks at all. Use Composer to pull in specific packages that you really need, and ask "if I can get the functionality I need from this package with an afternoon's work, is the package bringing anything to the table that I still want" before adding them. (Sometimes the answer is "yes," but not always, and I tend to be wary of packages that primarily just wrap other packages.)