In natural language (eg., English), the more complex and useful the idea you are trying to express, the more it behooves you to plan the structure of your writing ahead of time. Simple conversation -- meant to be used once to accomplish a singular purpose and then thrown away -- can't be designed. It's counter-productive. However, when drafting the constitution of a new country, it is imperative that you plan ahead in order to forge a document that will thrive and live beyond you, be maintainable, encourage improvement, but still contain the values with which it was forged. The same valuation applys to Perl, as I suspect it does to any language, machine or otherwise.

Of course Perl is a good tool for one-off quick tools; its "whipupitude," to quote Larry Wall, is par none. You can get away with this because one-off tools don't require maintenance or improvement. If they do, you'll quickly find that you are spending more time maintaining your tools than accomplishing anything useful with them, especially if they grow at all.

Perhaps, then, one of the most important skills to have as a coder is the ability to distinguish between things you will have to maintain, and those you won't. If you can conceive of the possibility that you might have to reuse your code, you'll always reap the rewards of a good design.