Yes, FOO() is clearer than FOO or (FOO). The latter two could be strings or file handles or perhaps other things.

Yes, you can't tell whether FOO() is a constant function and so whether FOO() gets called at compile time or at run time. But neither FOO nor (FOO) make that any clearer, either.

Earlier today you wrote

 my $tmp = io;
[download]

and io() isn't a constant, so you don't appear to reserve bareword usage for constants. So, how can the more ambiguous syntax be anything but less clear?

You know that the function doesn't get called at run time for constants. But that is an implementation detail and an optimization and so isn't particularly important. It doesn't change the function of the program and not knowing about it isn't going to trip you up when you try to understand what the code is doing.

I've certainly never been in a situation where I've slapped my forehead and said "Of course! That's why it isn't behaving right. I didn't (notice|put in) (the lack of|) the empty prototype!".

That was just a copypaste artifact I didn't bother to correct because it doesn't conflict with my convention anyway: all-uppercase BAREWORDS in my code are constants, except for the global filehandles predefined by Perl. (But I don't use bareword filehandles otherwise.)

There has even been an actual occasion where the compile-time inlining of constants tricked me, and in inocuous enough looking Perl no less. (It involved external code invoked by do to load configuration mixed with predeclarations — you can probably guess what happened.)

Makeshifts last the longest.