I am not saying you will automatically suffer from the following problems, but the following kinds of downsides to the template approach occur with such regularity as to have long since influenced me into starting every program from a completely blank sheet and only later going through my standards checklist:

1) what may seem often a good idea, even to the extent where it might deserve biblical reverence from users of this site, may still be inappropriate for some (even common) situations. Familiar cases of this include:

a) a one-liner perl -e being used in a shell script is usually too simple to be improvable by the techniques you'd apply to a fully-fledged script. The following example from a real system (of a quick XML out-filter/data counter), if padded out with 'use strict' and 'use warnings', would only tend to frighten any non-perl-proficient colleagues that might have to support it into concluding quickly that perl must be really dangerous and perhaps a reversion to awk would be a better idea, just in case!

#!/bin/sh
#... intervening code ...
export CountDataLines = `perl -e 'while(<>){/^\s*</ or $notXML++;} pri
+nt $notXML;' < $FileName`
[download]

b) use/require Module/File (!!!)

Rather than just use everything that is used somewhere in your project or even entire department's history, better performance and fitness to purpose can be achieved by conscious selection of libraries to meet actual usage by the current file you are working on.

2) Cut-and-paste-o-mania. Of course it might appear superficially that if using tested code then this must be a good approach, the downside to look out for comes in two deadly forms:

a) it encourages the use of an algorithm without understanding it - a common recipe for disaster.

b) it often creates more bugs both at parse time and runtime than if you'd started from scratch, because in reality there is more that can go wrong than you might imagine (different names, different dependencies, different looping/storage methods), when cutting code from one file and pasting it into another - even when the functional purpose is identical and even when the first file is as 'clean' as anything ever written!

(Update: I just realised that using my in a main program doesn't qualify as a global and have had to modify the following...) In regard to globals, only when their need is (update: on the face of it) detected do I then introduce the first and last of them (update actually i realise I don;t!) - a global (update: my-scoped, main) hash that can serve as a global dictionary whose reference can be passed around - in other words it is (er, actually not) declared global and never used as such apart from near the top of the main program...

my %gdd; Init( \%gdd)
[download]

...so that the subroutine Init begins (update: I have fleshed this out with some examples now):

sub Init
    #example of using a reference to a unique global dictionary
    my $gref = shift;

    open my $lh, ">>$ENV{ LOGFILE}" or Die( "$!: $ENV{ LOGFILE }" );
    $gref -> { FH }{ LOGFILE } = $lh;
    #...
    # example of initialising specific hash levels of a gdd using a lo
+cally scoped reference:

    for my $streamType qq( GSM SMS MMS ESP GPRS ) {
        $gref -> { ST }{ $streamType }{ BILLABLE }
            = ( $streamType eq 'ESP' ) ? 0 : 1;
        $gref -> { ST }{ $streamType }{ BYDURATION }
            = ( $streamType eq 'GSM' ) ? 1 : 0;
        $gref -> { ST }{ $streamType }{ BYVOLUME }
            = ( $streamType eq 'MMS' ) ? 1
            : ( $streamType eq 'GPRS ) ? 1 : 0;
    }
}

# example of using the FH for a logfile somewhere else in codeland...
sub SomewhereSomeModule{
    my $gref = shift;
    #...
    Log( $gref, 'description of functional phase' );
    #...
}
sub Log{
    my ($gref, $msg ) = @_;
    my $lh = $gref -> { FH }{ LOGFILE };
    print $lh MyTimeStamp() . ": $msg\n";
}
[download]

This is more manageable than having explicit global usages you have to remember all mixed up with other scoped identifiers in your code wherever you might be in your sources. Update: and I subsequently realised it isn't even global.

More Update: I suppose I should say how it is then possible to remain optimally efficient and effective:

1) the template can safely include a module/program comment heading plus use strict and use warnings.

2) the creation of package(s) to keep common functionality is far better than using templates for functional purposes - if there is a single sequence of actions that are required to do something in several places, why not have a single parameter-driven method that goes through the sequence in just one code location.