Well, yes, sure, you can still document your rules this way, but then you loose the concision. In that type of situation, I usually prefer a series of individual next statements (as you said, less risk of operator precedence mistakes). I would use the more concise form with several or only when the rules are more or less obvious or self-documenting. For example, in a procedure where I wish validate a date format, I could possibly have something like this:
in reply to Re^4: Remove blank lines from REGEX output
in thread Remove blank lines from REGEX output
Although this is a somewhat silly example, as this is certainly not good way to validate a date (it would not reject 31 Feb., for example), but it could still be useful in some cases to check the date format (do I have, as expected, dd/mm/yyyy or is it something else such as mm/dd/yyyy, yyyy/mm/dd or still something else), or to check that this piece of data is really likely to be a date and not, say, some numbers representing something else such as, say, a phone number, an IP address or whatever.
next if $day_in_month !~ /^\d\d?$/ or $month_nr !~ /^\d\d?$/; # one or
+ two digits
next if $day_in_month < 1 or $day_in_month > 31 or $month_nr < 1 or $m
+onth_nr > 12;
next if ...