Yes, it should. The fact is that the precedence of the bitwise operators is broken and this will finally be fixed in Perl6 (this has been broken since C).

I agree that most of the time you don't have to worry much about precedence because it was well designed. There are a few exceptions:

1. Bit-wise operators. They should bind tighter than comparison operators but don't. How they should bind compared to arithmatic operators is not clear but I find it never turns out the way I'd like. So I pretty much enclose all bit-wise operators (including shift operators) in parens and when I forget to do that I usually get bit by it.

2. Putting assignments in expressions. Although     $bool=  $x == $y; is probably less common than     if(  0 == ( $cnt= get() )  ) { the fact remains that assignment binds more loosely than nearly anything so those parens in the second example are required.

3. Don't do     open IT, "< $it"  ||  die "Can't read $it: $!\n"; because you should use or for that instead.

As for adding parens to make the code more readable, my personal preference is to use whitespace instead. Perhaps it is just me but I don't find nested parens at all easy to match up with the naked eye. But if I have a long expression with some parts separated by single spaces, other parts separated by double spaces, and maybe one triple space, I find the grouping obvious. If I need to go to more than three levels, then I probably need to throw in some intermediate named variables to make the code easier to read anyway.

Even in something like (0 <= $x) && ($x <= 10), I find that the parens do a very poor job of conveying the grouping. The "(0" looks more like a group because of the spacing. /: That is why I always put spaces inside my parens: ( 0 <= $x )