Pat, it comes down to this.
If you've been writing code for ages, and you've ever said "There has to be a better way to do this", and you haven't made your own "better way", then you might want to look at a framework using your use case.
If you have been doing similar work using the core Servlets platform for any length of time, you have most likely managed to develop "your own framework". Perhaps it is better than the devils you don't know out there in the world of frameworks, in terms of elegance, etc. Perhaps it's worse, but it's "good enough", and the intimate knowledge you (and ideally your team) have of your internal library of utilities more than compensates for anything that a new framework may offer simply in terms of risk and speed of development for you and your team.
Simply put, the reason to not use a third party framework is 'You don't know it, don't have time to learn it, and can't risk falling in to a black hole of uncertainty because of it".
No framework can address that. If that's the concern, then you should sign off with "Thanks for the conversation" and go on your merry way. No harm, no foul.
All we can say is that in our experience, and some us have pretty good experience in this domain, for some time, we have found that the frameworks (in our case, Stripes) have been a Net Win overall. And I've been bitten by black holes, unknown surprises, etc. But none of them have convinced me that the choice was wrong. Rather, we simply fixed the issue and moved on.
As I've said before, I think anyone new to the Java Servlet platform should write a non-trivial application in pure JSP and Servlets. Pure JSP and Servlets can go quite far with even the most minor amount of tweaking (like pounding out a quick Front Controller so you don't have to use raw Servlets everytime -- hardly rocket surgery).
But it seems to me that after you've endured that experience, you should have enough experience to make a sound decision to use one of the several dominant frameworks available. The time spent on that research and adoption will be minor, long term, to carving that wheel out of stone again.
In your case, you may well have already solved the problem. You've already got util functions, idioms, and tooling to make writing an application easier than using raw servlets. I can't advocate that anyone switch out a mature, working infrastructure for "something new". That's crazy.
That said, tho, I think that it would still be worthwhile for you, if you have time, to explore some of these frameworks. If nothing else, you may learn something that you may well want to apply and incorporate in to your current code base.
JPA is a classic example of that. JPA/Hibernate/ORMs in general have swept the Java world by storm, and for good reason. They're really nice, and they really work. They have problems, they're imperfect, and they introduce a large layer of "dark matter" in to your system that only hands on experience can decipher. But, in the end, for us, JPA has been a net win, and it's hard to imagine doing persistence any other way unless absolutely necessary. In the end, it's another tool in the tool box, but it's also the first tool we reach for today.
We're constantly looking at the new things available and try to take advantage of opportunities to try them out in anger on a real project. We take advantage of our long experience in knowing what we already know, and being comfortable that as we move down the path trying something new, we always have a backup plan should something go awry. With reasonable modularity, layering and testing practices, yanking out a new technology to replace it when it "goes bad" with an old technology is rarely a big issue. If it was a big issue, we wouldn't have done it at all to begin with.
Sounds to me you're happy with your code and your practices. If you have time, look at some new stuff if for no other reason than to get an alternate point of view of the problem, otherwise, no big deal.
I use Stripes on my own projects, and at work. I use, probably, 20% of the platform. I'm a big fan of its binding model, that's the Silver Bullet for me as it eliminates so much boiler plate garbage from my code. The other Stripes guys use far far more of the framework than I do. I'm the luddite of the Stripes community.
That said, I find it invaluable. I can't really fathom writing a system that responds to HTTP requests using anything else. To anyone reading this thread, if you need to respond to an HTTP request (whether that response is a forward, redirect, or streaming PDF, XML, or JSON), there isn't anything better, faster or easier than Stripes for the 95% use case. It's painless to use, and painless to incorporate, and Solves The Problem elegantly and efficiently.
If you like the Servlet model of web development, Stripes is the best evolution of that model available.