As said by gaal, in OOP code it's a common idiom; Learning Perl Objects, References and Modules suggests using shift.

I also find the shift idiom useful when I have a function that acts on a list of arguments based on the very first parameters; in this way, instead of:

sub somesub {
   my ($first, $second, @list) = @_
   foreach my $element (@list) {
      # do something, possibly intelligent
   }
}
[download]

you can avoid a list copy using:

sub somesub_nocopy {
   my $first = shift;
   my $second = shift;
   foreach my $element (@_) {
      # do something, possibly intelligent
   }
}
[download]

BUT this way you can produce side-effects outside the functions, due to @_ aliasing, so you've to be careful; from perldoc perlsub:

Any arguments passed in show up in the array @_. Therefore, if you called a function with two arguments, those would be stored in $_[0] and $_[1]. The array @_ is a local array, but its elements are aliases for the actual scalar parameters. In particular, if an element $_[0] is updated, the corresponding argument is updated (or an error occurs if it is not updatable). If an argument is an array or hash element which did not exist when the function was called, that element is created only when (and if) it is modified or a reference to it is taken. (Some earlier versions of Perl created the element whether or not the element was assigned to.) Assigning to the whole array @_ removes that aliasing, and does not update any arguments.

Update: rephrased to avoid implying that gaal is suggesting to actually use shift other than for facade methods.