I found this bit odd:

Do not use shift. Use @_. shift is slower, and Brian has an allergic reaction to it.

        my $var = shift;                        # wrong
        my($var) = @_;                          # right
        sub foo { uc $_[0] }                    # OK
        my($var1, $var2) = (shift, shift);      # Um, no.
[download]

I always use shift, and I recall benchmarking it way back in the day before I made that decision, just to make sure it wasn't slower. Here's the test I used, and the results:

use Benchmark qw(cmpthese);

sub x_shift
{
  while(@_)
  {
    my $a = shift;
  }
}

sub x_copy1
{
  for(my $i = 0; $i < $#_; $i++)
  {
    my $a = $_[$i];
  }
}

sub x_copy2
{
  my $end = $#_;

  for(my $i = 0; $i < $end; $i++)
  {
    my $a = $_[$i];
  }
}

my @args = (1 .. 100);

cmpthese(1000000, 
{ 
  x_shift => 'x_shift(@args)',
  x_copy1 => 'x_copy1(@args)',
  x_copy2 => 'x_copy2(@args)'
});
[download]

             Rate x_copy2 x_copy1 x_shift
x_copy2  609756/s      --    -18%    -45%
x_copy1  746269/s     22%      --    -32%
x_shift 1098901/s     80%     47%      --
[download]

Seeing the flat claim that shift is slower made me rethink my earlier test and try something more simple:

use Benchmark qw(cmpthese);

sub x_shift { my $a = shift }
sub x_copy  { my $a = $_[0] }

my @args = (1 .. 3);

cmpthese(1000000, { x_shift => 'x_shift(@args)', x_copy => 'x_copy(@ar
+gs)' });
[download]

Sure enough, the results changed, but now it appears to be a tie:

             Rate  x_copy x_shift
x_copy  1298701/s      --     -0%
x_shift 1298701/s      0%      --
[download]

The results fluctuate a few percent in each direction. Anyway, my point is that I don't think performance is a reason to avoid using shift.

(I have a whole directory of benchmarks for silly little things, e.g. benchmarking exists() vs. a test for truth on a hash key and crazy stuff like that. It's a disease...but it amuses me :-)