Opinions vary wildly on this point. So, since you ask here, I'll give you my two cents.
I came to the framework game honestly. I'd already spent nearly 20 years programming by the seat of my pants. I started professionally in machine language, (that's right later it was a joy to have an assembler!). I was poking endless hex numbers into memory locations and loving it!
Many years later at the end of a long chunk (nearly 10 years worth) of mostly Perl work, found myself in a large company that was sinking because the huge krufty pile of Perl that we called our 'Enterprise' was failing to bill a huge amount of our customers and our massive database was riddled with integrity problems because nothing was planned. Our Enterprise had not so much been designed as it had accreted like a coral reef.
So the powers that be foisted Java on us. 'We're moving to a new paradigm,' they crowed. Meanwhile I (not-so) silently forked the sign of the evil eye at them and this new monster they were building. But it wasn't long before it became apparent that they would hang on to the Perl slingers long enough to prop up the aging garbage pile until the gleaming new machine was built and then they'd axe us. So when they came and asked be to join the Java team, I grudgingly went.
We were fortunate enough to have an insanely sharp contractor come in, lay down the infrastructure, all pattern-based, and he took the time to explain it to us. It was hard going and I complained every step of the way, but eventually it began to sink in and I realized by the time all was said and done, that I'd been missing out for a long time. Suddenly I had a much clearer picture of what I was doing, and could articulate it to others and expect them to understand right away when I mentioned the use of a Facade, or google until they did.
After learning to think about software in patterns, and doing several years of hands on J2EE work, I found Flex. I started dabbling, recreating a small but nontrivial app that I often use to learn a new language. Being on the client side was a little bit of a disadvantage at first as I was used to server side patterns and didn't know what was really applicable. So I just started hacking away. Of course I used everything I've learned over the years prior to learning about patterns in order to keep it simple and clean, and good stuff was happening right away, to be sure. But before long I realized that the classic issue in an OOP system of how to wire things up and pass data around without making a mess was as prevalent here as anywhere. I never did finish that app. It became unmanagable spaghetti code despite my best efforts, and when Flex 1.5 came out, I never carried it forward. By that time, I'd had the good fortune to find Cairngorm, and never looked back.
Some frameworks are
more pain than they're worth. EJB 2.0 for instance made you define 5 separate classes for every entity object. That was a bit much to cope with, and I can certainly agree with those who say using that particular framework is more trouble than it is worth.
But to accept or make a blanket statement such as 'Frameworks are more trouble to implement than they're worth' is to do yourself and others a disservice. Its all about where you are on the curve. If you'd told me that back when I was trying to wrap my head around Java, J2EE, EJB, and JBOSS all at once (against my will!!!!) for instance, I'd probably have socked you in the eye if it was a particularly bad day.
There is a quite good post on this topic by Steven Webster, coauthor of the Cairngorm framework here: http://weblogs.macromedia.com/swebster/archives/2006/08/why_i_think_you.cfm
Although I don't agree that if you're the only one who'll ever look at the code, there's no need to use a framework. I think the decision is governed purely by the potential complexity of the app.
Steven seems to advocate rolling up the sleeves without a framework first as well. Clearly, it's better to make a big mess by hand first. This helps you to know just exactly what it is you're avoiding when you use a framework.
As a point of professional responsibility, though, I would suggest making that mess on one's own dime and not that of a customer. -=Cliff>