You aren't really showing off different ways to get arguments in any of those examples. In all of them, you get the arguments in a list called @_; you're just showing off three different ways to get values out of a list, which Python has plenty of ways to do as well. Translating your examples into Python:

    def add1(*_):
        _ = list(_)

        arg1, arg2 = _
        return arg1 + arg2

    def add2(*_):
        _ = list(_)

        arg1 = _.pop(0)
        arg2 = _.pop(0)
        return arg1 + arg2

    def add3(*_):
        _ = list(_)

        return _[0] + _[1]

> So, how exactly these different ways of getting sub arguments are useful?

Because in the second (add2), you might do something interesting with the second (or third) arguments depending on the first. You might have optional arguments. Your arguments might be a list of items you don't know the size of. It allows you to develop what you need out of the extensible core mechanism. Modules can and have built on that.

> # There may be some other ways to extract arguments

There are. Now you can just do

    sub add( $arg1, $arg2 ) {
        $arg1 + $arg2;
    }

My personal favorite is to use Function::Parameters[1]

    fun add( Num $arg1, Num $arg2 ) {
        $arg1 + $arg2;
    }

which allows named params, type constraints (runtime), default params, etc.

1: https://metacpan.org/pod/Function::Parameters

To be a bit pedantic, these are not different ways to get a sub arguments, but accessing an array in different ways ("default array" in this case). If I understand this correctly, your criticism is aimed at how the core language makes arguments available to a sub body, in the default array.

The first example uses the explicitly named default array @_. This is a common pattern, and easy to read.

The second one omits the "default". Note that whilst it is possible to write some dense code between the $arg1 and $arg2, it won't work as expected if the dense code bit has array access - ie., the default array can change in the code.

The third example uses the typical sigils for accessing individual elements within an array (default or otherwise).

I wish the core language had saner defaults, but over time, I've seen some reasonable uses for the different styles:

1. General subs, the same as you example

2. shift removes the first element of the array and returns it. This can make the code more readable in certain cases:

  use Params::Validate 'validate';
  sub add2 {
    my $self = shift;
    my $args = validate (@_, { ... } ); 
  }

3. Slightly less verbose code, for simple one-liners and/or anonymous functions:

  my $calc_functions = {
    'add' => sub { $_[0] + $_[1] },
    'subtract' => sub { $_[0] - $_[1] },
    ...
  };
  my $func = 'add';
  $calc_functions->{$func}->($args);

The significant part of argument handling in Perl5 is that @_ is a list of aliases to the arguments. You usually see add1 or add2 style argument processing because nice named arguments that are a copies of the function parameters.

add3 shows how to access the aliased arguments directly.

  # break the aliasing of @_ and make undef into 0.
  sub undef_to_zero { @_ = map { $_ // 0 } @_; }

  sub math_stuff {
    # call with identical @_
    &undef_to_zero;
    # Do math without undef warnings.
    my $sum = 0;
    $sum += $_ for @_;
  }

  # Alter all arguments in calls by repeating them
  sub fatten {
    $_ = "$_" x 2 for @_;
  }

  $foo = "abc";
  @bar = ( 1, 2, 4 );
  foo($foo, @bar);
  say $foo; # abcabc
  say for @bar # 11
               # 22
               # 44

The second example is just bad code. The third example one would rarely use in oneliners or very shorts subs, maybe in a dispatch table. You can write atrocious code in just about any language. Perl 5.20 finally has function signatures anyway.

you'll be happy to know that the sigils (@) don't change in perl6 for access.

I see no problem here.