My experience is that you will mostly find rather strong reactions against using & when calling subroutines. However, the only problem with doing so beside over-zealous style-related reactions is that doing so also disables function prototypes. But, if you use function prototypes, you are also likely to get over-zealous reactions against doing such. So the real problems with using & are minimal or none.

On the other side, what are the arguments in favor of using & ? There is the style argument that you gave. The & provides a visual cue that the function being invoked is certainly not a Perl built-in (it can't be). You can also make the style choice of using & on functions local to the current package and then not using & on functions imported from other modules. It is funny that people who love Perl, including the ugly sigils it pollutes the code with seem to hate the red-headed step-child Perl sigil of &, despite it offering the same style / visual benefits.

But is there a benefit to using & other than style? Actually, there is.

#!/usr/bin/perl -w
use strict;

sub dump {
    require Data::Dumper;
    my $d= Data::Dumper->new( \@_ ) # The defaults are "all wrong":
        ->Indent(1)->Useqq(1)->Terse(1)->Sortkeys(1);
    return $d->Dump();
}

print &dump( @ARGV );
[download]

Since I didn't use a function prototype, surely I can just drop that "ugly" & and nothing changes.

Note that the above problem doesn't happen for:

use A::Module qw< dump >;

print dump( @ARGV );
[download]

actually reinforcing the above style choice of only using & on subs local to (defined in, not imported to) the current package.

I solve that problem by capitalizing all of my subroutine names. Of course, that just leads to me learning that there are quite a few people with rather violent style-based reactions against the dreaded and ugly CamelCase. But at least I get to pick which group grumbles at my code. ;)