And I consider parenthesizing for clarity to be a good practice. (Note that had kha0z followed that practice with the tie we would not be having this discussion right now...)

FWIW I am in good company with my opinion, in perlstyle adding unnecessary parentheses is listed as a "more substantive style issue". The relevant section says:

           Along the same lines, just because you CAN omit
           parentheses in many places doesn't mean that you ought
           to:

               return print reverse sort num values %array;
               return print(reverse(sort num (values(%array))));

           When in doubt, parenthesize.  At the very least it
           will let some poor schmuck bounce on the % key in vi.

           Even if you aren't in doubt, consider the mental
           welfare of the person who has to maintain the code
           after you, and who will probably put parentheses in
           the wrong place.
[download]

In fact the only common mistake with parentheses that I know of is being tripped up by the fact that print is a function. I consider learning that fact to be far less to ask than any significant part of the precedence table. Particularly since a messed-up print tends to be far more obvious mistake than a non-functional error check. (I try to test my error checks, but I know full well that most people do not...)

UPDATE
I agree that it is situational. If you come from C then the precedence is pretty much trivial because the table is (intentionally) the same. For people who are not from a C background or whose C is rusty... (And yes, I have seen similar code from people used to C trying out Perl.)

Point taken. Perhaps it's situational. I see far more problems with context confusion than I do mistakes with operator precedence, but that may be because I'm working with a set of people who've come up through C/C++.

Their C/C++ backgrounds shows itself by way of things like

  if ( ($x > 0 ) && ( $y < 0 ) ) {
      return ( 1 );
  }
[download]