Yes, I agree with you, Rolf, it is true that there might be a problem of understanding, but the construct is so practical that that I think it is worth the effort. Besides, it is easy to force precedence with parens:
open my $FH, "<", $in or (print "cannot open file $in\n" and exit 3);
so that, in fact, replacing curlies by parens in the OP's code might really be all that is needed to make it work if I did not miss anything (I haven't tried it in real context).
Besides, as far as I understand it (but I may be wrong on that, I haven't investigated very far), it seems to me that it is not really a issue of precedence between the operators, but a simpler question of left to right Boolean evaluation with the right part of the expression simply not being evaluated if not needed (i.e. if the left part is true with an "or" operator, or if the left part is false with an "and" operator).
Consider these two one-liners (I have an xml.pl file in my current directory, but no xml2.pl):
$ perl -e 'open my $FH, "<", "xml.pl" and print "Opened!" or print "ca
+nnot open file\n" and print 3'
$ perl -e 'open my $FH, "<", "xml2.pl" and print "Opened!" or print "c
+annot open file\n" and print 3'
cannot open file
This seems to work fine in both cases. I am of course not suggesting that such bizarre code should really be used for anything useful, but I am just pointing out that this would not work, I think, if we were to rely on the fact that the "or" operator has a lower precedence than the "and" operator.