Security is the Most Compelling Reason to Use a Framework
I've written microframeworks for web applications in the past. I even have one running right now for my own personal use, managing mailing list tasks and bounce processing on one of my other sites. You generally find yourself putting the finishing touches on a microframework sometime after a conversation with yourself that starts "it's ten web pages and a few widgets, why roll out something like Drupal for that? How hard can it be?" Or CakePHP, or Symfony, or pick your framework and language of choice. But even ten pages and some widgets generates enough common code that you'll wind up with a page generator and a request router and some other classic microframework components by the time you're done. No sense in writing a function twice when it can be written once, right?
Which is all fine and good; writing microframework code is soothing in a zen sort of way. It also teaches you something about what has to take place inside larger frameworks, which in turn helps greatly when it you find yourself needing to learn the ins and outs of a new framework in a hurry. When I say "microframework" I suppose I really mean that this is how you've chosen to organize the code for a small web application. Maybe some pieces could carry over to another one, maybe it won't be worth it. If you prefer, the term microframework might be more akin to a narrow domain-specific language established for the problem space of this one web application. Whichever.
There is a problem, however. The problem is that at the end of the day most developers who take the roll-your-own-microframework path will have built a fundamentally insecure web application. Whether or not the work was soothing or entertaining or educational is somewhat beside the point given that result. I would go so far as to say that security is the core and principal issue that should drive the decision on whether to use a significant framework or not, even when producing the most trivial of web applications.
Take a look at the XSS Cheat Sheet, for example. Do you feel up to building and maintaining test code for a web application in which you are responsible for ensuring XSS security? And that is just one of a number of equally daunting security areas associated with modern web development. The more you learn, the more you realize that your application accepting any sort of input from out there in the wild online world is downright intimidating - or at least the amount of work required to prove to yourself that you're doing it safely is downright intimidating. One or the other.
The solution here is to use a significant open source framework that has existed for years, is widely used, and has thousands of developers associated with it in some way. That choice essentially outsources the basic, required, but very intricate and in-depth security work to the people who are best at it and have the most knowledge. The end result won't be perfect, as no software is perfect, but it will be far, far better than you can do yourself. It's the best possible way to ensure that people who know what they are doing have worked on the security of your web application and are continuing to work on maintaining that security against newly discovered threats. This doesn't mean you can stop thinking about basic good sense when it comes to application security, but it should mean that you can finish up work without having to fully understand every last detail on the XSS Cheat Sheet and other, similar documents, and yet still produce a secure end result.
Specialization and collaboration between specialists leads to better producers and better products - it's the foundation of the road to wealth and trade. But here, in web development, security stands out as an area which in the benefits of developer specialization are the most important for the average developer. Near every web application requires serious thought when it comes to the basics of security, but few developers are specialized enough in web security to be able to do justice to the security of their applications. This is absolutely fine, given that nothing would ever get done if we all specialized in security rather than the hundred other specialties needed in web development, provided that developers do in fact use the good work of others - which here means refraining from rolling their own microframeworks.
That microframework running as a part of one of my other sites? I should have used an established web framework, given that the amount of time I've put in to satisfy myself that I'm safely accepting user data is probably greater than the time it took to build it and get it running in the first place. So don't put yourself in that situation, unless you really want to make web security your hobby - it'll put a real hole in your productivity.