The performance issues notwithstanding (that is a discussion for another day), I think it comes down to a matter of style and personal taste. You have to ask yourself, "Is it easier for me to keep tabs on what is going on in a larger program or several smaller ones?" The answer could vary from coder to coder.

The Perl literature is relatively quiet on the issue, with the exception of O'Reilly's CGI Programming which dedicates a few pages (378-381) to the subject. In a nutshell, the authors favor the larger program model for the ease of editing (having to open, know, and look at only one program), and distribution (only one). The smaller programs would be better when several programmers are working on the project, or for security reasons—allowing access to programs by only those that need them.

Our own Perl Monks tend to favor the former model, one biggie, with the option of putting commonly used subroutines into a module (or see another PM Q&A).

Here is a summary of their comments:

On subroutines:

• group your subroutines by task, minimizing the calls between subs in different sections; separating sections clearly in your code
• be able to describe what a subroutine does in one sentence, without using "and" or "or"; i.e, clearly define a single task for each subroutine

On modules:

• "If you could simply wish any module into existence (within reason and logic), can you imagine any that would simplify your design? 'Gee, if the Such::and::Such module existed, I'd only have to do this and this, which is really the core of my application, and not all this other stuff.'"
• "Design your functional blocks so that they have minimum cohesion between them. In other words, minimize interaction between modules at the same level."
• "Keep the size of a module to less than a few pageful." (I've heard 50 lines as a gauge)

Refactoring: streamlining your code
This is process of methodically editing your code to optimize it for speed, size, and efficiency. Here's a very thorough example of refactoring.

And here's a more thorough discussion of program design.

Thanks to tilly, Art_XIV , Demerphq, Roger, and the ubiquitous Anonymous Monk.