work($a,$b,$c,$d,$e,$f);

sub work{

    my ($a,$b,$c,$d,$e,$f) = @_;
    more_work($b,$c);
    print "$a\n";
}

more_work{

    my ($b,$c) = @_;
    even_more_work($c);
    print "$b\n";

}
[download]

$d, $e, $f are never used, and $b & $c are only used by more_work().

Then perhaps what you should be doing is:

more_work( $b, $c );
work( $a )
[download]

Or if work() requires the results of more_work(), then maybe:

work( $a, more_work( $b, $c ) );
[download]

I realise that your example was just that, but it demonstrates the problem with using made-up examples rather than real ones. It becomes all too easy to exaggerate the effect of the perceived problem -- that of passing lots of data around -- whilst obscuring what is often the real problem -- poorly structured code.

That looks like a candidate for some light weight OO and named parameters. Consider:

use strict;
use warnings;

my $obj = bless {flibble => 1, floop => 2, flop => 3};

$obj->work(nuts => 7, bolts => 5);

sub work{
    my ($self, %params) = @_;

    $self->more_work(%params);
    print "$params{nuts}\n" if $self->{flibble};
}

sub more_work{
    my ($self, %params) = @_;

    $self->even_more_work(%params);
    print "$params{bolts}\n" if $self->{floop} > 1;
}

sub even_more_work{
    my ($self, %params) = @_;
    my $sum = $params{nuts} + $params{bolts};

    print "$sum\n" if $self->{flop} == 3;
}
[download]

Although in real code a constructor would check important parameters and subs would check that any required named parameters are as expected.