I urge you to read the first full sentence under the heading in the documentation I posted.
The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive
And I don't think you need to in order to assume the correct functioning of
print $x if $x;
As much as you may find it compelling to point towards it's possible interpretation as
print( $x if $x );
I find that interpretation nonsensical, and anyone making any effort to learn how the language works or if not that, at least think about what it could mean and what it
probably means will
not be surprised. Perl tries to Do The Right Thing (DTRT) whenever possible, and with this principle in play, I think the meaning of this statement is very obvious.
Even if we extend the statement to be somewhat more ambiguous, a bit of thinking about the problem makes it obvious what the right thing to do is, and it is indeed what Perl does:
print $x, $y if $x;
# OR
print $x, $y if $y
You can either interpret that as Perl does, or as:
print( ($x), ($y if $x) );
# OR
print( ($x), ($y if $y) );
Do you ever really want something like that? Is that useful to you, given that there are a few other ways of achieving that which are much less cumbersome ($y||$y)?
The point is that in any well designed product you shouldn't have to study the docs (all that much) in order to start being productive. And there should be as few "gotchas" as humanely possible please. Did I say pretty please?
It's almost comical that you are making this argument. One of Perl's strong points is that it's really easy for someone to pick up and start using, because it tries to DTRT, making it very easy for the beginner.
Long-time Perl hackers tend to forget their first experiences with the languages (which for many with languages with far worse track records on the consistency / simplicity scale). But newer users have (rightfully) come to expect much better.
When I mention Perl, I still hear people immediately jump out with "Oh, I remember I used Perl back in the day and it was real easy to whip up a little program to do what I wanted."
I think what you are running into is that you have experience and expectations with other languages, and when Perl doesn't match those expectations, you blame Perl, rather than meeting it at it's own level. I suspect you don't do this as much with languages that appear radically different, such as Haskell and Lisp. If so, is that Perl's fault for following a different path, or yours for failing to use it appropriately?