They're sort of okay for the lone wolf working on a simple project; something not too terribly different from the basic "Hello World" CRUD app that comes with the documentation and tutorials. It is incredibly simple to do simple things, as long as those simple things match the paradigm perfectly. And there is an argument to be made that for very large projects with teams of developers maintaining a huge code base, somehow the "discipline" that the framework imposes will make the code magically more maintainable and extensible. You know what? The same argument was made for J2EE, and all that got us was:
AbstractFactoryFactory factoryFactory = FactoryFactoryGenerator.createFactoryFactory(FACTORY_CLASS_ABSTRACT);
//it's up to you to remember that FactoryFactoryGenerator is static
//and that an AbstractFactoryFactory needs to be instantiated
Boilerplate everywhere that does nothing and meaningless (and, frankly, nonsensical) class hierarchies. The concepts of data hiding and method hiding go beyond run-time permissions; you literally can't find them without grepping the whole repository (or using a monstrously slow IDE to do the grepping for you). Oh, and there's this whole MVC thing that's en vogue that really isn't MVC and doesn't actually work on the web like MVC in a rich client would without websockets (and if you're not on a VPS, dedicated or colo server, you won't have websockets — which you can't really use on a public-facing websites anyway because of older IEs).
PHP, for instance, is already a templating language. And while you can stuff your whole application into a "template", there's no law that says you have to. There is no fundamental difference between simple emission code on a PHP page and a tagset that does the same thing. They both require domain knowledge, so the argument that a "pure front-end designer" can create a template without any knowledge of the system is an outright lie. All the silly add-on templating system buys you is added processor cycles; a developer (or a designer with knowledge of the system) still needs to translate the HTML into a template. PHP tags and an understandable emission API will do the same thing faster and in less memory space.
Object-oriented procedural code is similarly silly. It's not a substitute for namespaces, lambdas or closures. If it ain't a "thing", it shouldn't have a taxonomy or a behaviour — unless the language is truly object-oriented (that is, everything is naturally an object, including primitives). Static methods in static classes are a way of admitting that you'd rather type a couple of colons (in PHP) than manage dependencies. You get the same naming safety with an underscore and a require. Closure will get you static data. All you've gained is boilerplate.
An ORM will also be quite useful if the data really doesn't need much work. If it does need work, then you have to do a lot more in the database (triggers, foreign keys, stored procs), which will tie you to a single RDBMS and even to a single version. That's cool if you have DBAs on hand. A lone developer or a small team probably won't, so they'll have to write a parallel ORM of their own anyway to do what the one in the box doesn't do. So now you have two sets of files being loaded, lexed, parsed and clogging up memory — for what gain?
So yeah, a framework may be great for a toy app. And it may be great for "factory floor" development using huge teams of interchangeable code monkeys who can't be trusted to do anything unless somebody else makes the bricks they're putting together. If you want a job in an Enterprise IT cube farm, they may be worth knowing (although Java and .NET will probably get you more opportunities). But for anything fast, light, interesting or programmatically non-trivial, they're a hindrance rather than a help.