I've used frameworks and written my own. Obviously what works better depends a lot on how similar your problem is to what the makers of the framework intended to solve. The dilemma is that as you build your app your problems become more specific to that particular app and you tend to gain less and less from the framework. Eventually the framework gets in your way. Not because it forces you to do it in a particular fashion, but because you feel compelled not to stray from the framework's path in the interest of consistency and simplicity. Unfortunately, the same may be true of your own framework creations, just the consequences are different.

Frameworks are great if you do a series of similar, straightforward projects like many contractors would do. A framework allows people to get acquainted with your code more quickly, so it's good for companies with high staff turnover. It also has a name that HR can put in a job ad.

If you roll your own, try to do it as a collection of independent libraries, not as a don't-call-us-we-call-you type of framework. That's my conclusion after many attempts at framework writing. It has always been the case that some parts were good and others were crap. You can't throw the crap out if everything is interconnected. The code that connects everything needs to be either the smallest part of the framework or part of the application itself.

But anyway, as long as you stay away from CMS, you're going to be fine.