Do *you* know what it does? If so, then your advice surprises me. What it does is prevent a Perl built-in from being called if your subroutine name happens to collide with the name of a Perl built-in. Why should anyone avoid that protection?

& disables prototypes and inlining. If used without parens and arguments, it implicitly passes @_. That alone should be a good reason for telling newbies to avoid using & when calling subs, or to always use parens. I think it's much better to simply say that & is not to be used unless you know why. Same goes for symbolic references, local (actually, package global variables in general), steak knifes and bicycles.

Calling a sub without the ampersand is faster. This doesn't matter of course, but perhaps this shows how the newer style is optimized.

Quoting a usenet post by tchrist:

(...) You can spot a an old, perl4ish, non-ORA, and/or non-lwallian book a league or seven away by its obsequious allegiance to an ampersand.

Quoting perlsub:

Not only does the "&" form make the argument list optional, it also disables any prototype checking on arguments you do provide. This is partly for historical reasons, and partly for having a convenient way to cheat if you know what you're doing. See Prototypes below.

(...)

(...) If you call it like an old-fashioned subroutine, then it behaves like an old-fashioned subroutine. (...)

Quoting perlstyle:

(...) Call your subroutines as if they were functions or list operators to avoid excessive ampersands and parentheses.

Also note that you should use & without parens with defined or to get a reference to a named subroutine.

I explicitly discussed *calling* subs with &. You do of course need it when you syntactically treat the sub as a variable.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }