Lack of parentheses visually distinguishes builtins from subroutine calls

Hm. Apart from the fact I don't need to use the addition or omission of parens to distinguish between built-ins and not; because in common with most (not all; but most), programmers I use a syntax highlighting editor that is capable of doing that for me.

That distinction is wholly artificial.

For starters, there are some places where the parens are not avoidable without jumping through contorted hoops that would completely negate any benefit of their omission. Eg.

print '(' . join( ',', @things ) . ')'; ## (1,2,3,4,5,6,7,8,9,10)

print '(' . join ',', @things . ')';;   ## (10) Whoops!

print '(', join ',', @things, ')';;   ## ( 1,2,3,4,5,6,7,8,9,10,) Doub
+le whoops!
[download]

It also presupposes that everyone will always use, often redundant, parens on every non-built-in.

And then the definition of what is a built-in and what is not gets blurred when you start using (for example),

• Math::Random::MT qw[ rand srand ];
• Time::HiResqw[ time sleep stat ... ];

And at least one of those, behaves quite differently to the built-in in many circumstances, if used without parens.

Also, I realise you're only paraphrasing, so the fault, (if there is one,) may be yours not the books, but aren't those first two "reasons" actually just one? Ie. Enhanced readability by reducing clutter. or By reducing clutter it enhances readability.

I greatly prefer, and practice religiously, the "low clutter style" of Perl coding, and I think that the results are self-demonstrable. I don't see any additional benefit from overselling them with justifictions.