|laziness, impatience, and hubris|
Do things once, no more.
Like the third normal form in database design, it's a noble vision; you may decide to violate the rule for practical reasons. But it better be a good reason :)
In this case it might be readability, but I would try to counter that problem with a good naming convention and properly defined (yes, documented) interfaces first.
<Drifting off-topic> Actually, I wrote an essay about Object Oriented Maintenance once which discussed an interesting problem in this area. Object oriented code tend to contain a lot of small (few lines, like 3-6) methods. Each method is easy to understand, but the overall system understanding is more difficult due to the "fragmented" nature of the code (and other OO things, like late binding).
The studies I used in my essay contained mostly Smalltalk code, other languages had other but similar charachteristics. As for Perl... well, TMTOWTDI.
<Further off-topic> The solution I suggested for this lack of system overview was better dev tools. With class browsers and automated documentation systems things improve. And POD is a truly great thing with Perl.
Both "Code Complete" and "The Pragmatic Programmer" contain advice regarding subroutines.