I don't think you're missing anything. It seems to me a nice MVC design that allows you to separate concerns cleanly is the way things are going right now. There are several excellent Perl modules that have come out in the last year or two that are all hitting this key area. Some have been mentioned above. We use CGI::Prototyped.

Yes, the HTML part is tedious, but I think it's still necessary for a few reasons:

• Different people working on different parts. As already mentioned, in many places different people work on the HTML and the business code. Better to let the HTML people work in something close to a standard language.
• Prototyping is much easier when the designers can mock things up in HTML and easily convert that to a working app using most of the prototype. If you have a meta language in there, less of the prototype can be used as-is.
• Custom requests still happen all the time, at least in my shop. You may come up with a CRUD design that you can just crank out, but we still end up with special requests for changes to the look and behavior. This is easier to accommodate and maintain in a separate HTML-based view.
• Maintenance is easier with a standardized system. You can pass things off to others and they can figure it out because the view is based on some standard module like Template. The business code is in straight Perl. The DBI code might be in Class::DBI. Tricky automation systems can be very cool, but they can also be fragile.

Given the limitations of the web as a medium for allowing people to do work, I know I have felt that using these MVC Perl modules is light years ahead of where we were. With the INCLUDES, WRAPPERS, and MACROS in Template::Toolkit and the OO inheritance provided by CGI::Prototype, we can re-use just about as much common stuff as possible. Yet we can still be responsive to custom requests at the HTML/CSS layer.