Is there ... some hidden trap for the unwary--behind this statement?

Yes, but it's not hidden. The precedence difference is documented. It comes up often enough, but I can't remember any examples.

Or is it just another icky meme based on personel preference and groundless dogma.

None of my style decisions are groundless.

my style decisions

That sounds a lot like "personal preference".

And if "the precedence difference." is your justifiction of entreating other to [only] "Use && and || inside of expressions.", and you "can't remember any examples" of how not following that entreaty will cause any problems, (beyond perhaps offending your sensibilities), then it also sounds pretty groundless.

As someone once said: In the absence of evidence, opinion is indistinguishable from prejudice.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

That sounds a lot like "personal preference".

Of course. Why would I be advocating a position other than my own.

And if "the precedence difference." is your justifiction of entreating other to

No, it's traps resulting from that precedence difference.

As someone once said: In the absence of evidence, opinion is indistinguishable from prejudice.

Did you read the parent post at all? I have seen evidence of it causing problems.

There have been a few such examples that have been brought up by SoPW. I don't recall the details of any of them either, but it is pretty straightforward to build an example.

If you use the wrong operator (&& vs and) then a number of low precedence operators will not behave as you expect:

use strict;
use warnings;
print "&&: ";
print 1 && 1 ? 0 : 1;
print "\nand: ";
print 1 and 1 ? 0 : 1;
[download]

This prints:

&&: 0
and: 1
[download]

So, if you don't mind your code doing completely unexpected things, then you don't need to distinguish between "&&" and "and".