If function-oriented programming is a screwdriver, OO is a bench drill.

Do you have a big, heavy lump of problem that needs some serious torque, or do you just need to screw someone's comments onto an email? What OO gives you is organisational power, but it comes with a price: time. If you're writing a major online application (like Perl Monks!) try sticking to OO. As you code grows, you'll still be able to see the over-all shape of it. Better yet, people maintaining your code will be able to get a handle on it. If it's a standalone scriptlet, OO will double the size of your code for no reason. Choosing OO CGI modules will help you keep the rest of your code OO.

Interestingly(1), I've been thinking about this very subject today. I've started rewriting our office intranet, which started out as just a support ticketing system, but has grown to include project management, document handling, DNS database administration, an address book, a skinnable interface and optional sidebar nodelets. At the moment, it's a mixture of some loosely-integrated PHP, a few Perl CGI scripts, some ColdFusion and some magic. Some applications have their own entire databases and user lists. Some reside on completely different servers. What I've started doing today(2) is breaking all the managed things into classes, and defining their capabilities in a class definition. The request procedure for the new single-application-multiple-functions intranet will involve one handler script setting up global objects representing the datasource, the logged-in user and a few other things, then calling a top-level page template object, which will, in turn, call the objects required to draw the page. I also, along the way, define an object API to easily extend the intranet's functionality. Thus, the nightmarish task become manageable.

Sorry, I've rambled. What was your question? :-)

(1): Or not.
(2): Working on a Sunday. Tsk.