When you already have the M, how well does your MVC framework do? O'Reilly editor Andy Oram points out in MVC frameworks and the power of legacy databases how existing databases are a big problem for frameworks that want to make the schema decisions for you.
I've always kinda wondered about how people did real problems. It's a tough thing to show real problems in a demo, so people make toy applications from scratch where they get to decide how things get stored and how they get their data. How does that ORM stand up when you have to get data from multiple sources in different way, such as screen scraping a mainframe for some data but hitting a database server for the other parts? That's a situation I've actually had to program around. Or how about fetching records through a web service as part of the model? When you play with big things, you often start in the middle of a problem after other people, perhaps years earlier, designed something.
That's one of the reasons CGI::Prototype exists. It gives you almost nothing. You can use something like DBIx::Class, but CGIP knows that real work is often complicated enough that you end up overriding lots of any framework, so it doesn't give you much to override. "Default over configuration" might be fine when you can accept defaults, and configuration might be fine when you just need to set-up something, but neither really work for strange problems (and anything interesting seems to be strange). CGIP gives you hooks to fill in any way you like. It's certainly work, but not more work than wrestling with a framework that wants to put your square peg in its round hole.
However, anyone who tells you which framework to use before they even know what you are doing has no real idea which framework might work for you (and should STFU).