I think it actually gives a nuanced answer to your question "where do you draw the line", namely: With a partial precedence scheme, one does not need explicit parentheses for those operator combinations for which the precedence is "clear enough". E.g., in "3 + 2 * 4" precedence is clear to virtually all programmers because it follows standard rules from math ("PEMDAS"), so that is why the precedence table in the post specifies an ordering. However, especially for operators which are less frequently used, or where precedence does differ between languages, one should give parentheses for clarity. I think this is a very sensible argument.
I have certainly made errors because of unclear precedence (e.g., with boolean operators, exponentiation, casting etc.) in the past. And given that there even is a CWE number (https://cwe.mitre.org/data/definitions/783.html) for this kind of error, it seems frequent enough to warrant discussion.
If I invent a crazy unit system for measuring distances, where a "finger" is 8.3 centimeters and a "storey" is 246 centimetres and start using it in my writing, can I really blame others for "anti-intellectualism" when they refuse to learn my arbitrary new unit system?
The problem with operator precedence is just that - any operator precedence rule is an arbitrary convention. I'm not saying that conventions are never worth learning, but it depends on (1) whether such convention is already well understood, and (2) whether the benefit of such conventions outweigh the trouble of requiring everyone to learn it. The precedence between * and + clears both criteria: most people have learned during school, and it's quite common to use both * and + in the same expression that defining that * binds tighter than + can save a lot of parentheses. On the other hand, combination of + and | are rare enough that the benefit of such conventions doesn't outweigh the confusion it could cause.
On the other hand, combination of + and | are rare enough that the benefit of such conventions doesn't outweigh the confusion it could cause.
Maybe for you it is, but for others it isn't.
I suspect a lot of this "refusal to learn" sentiment is actually driven by management attempting to turn developers into easily replaceable, expendable "resources". From that perspective, lower-common-denominator dumbing-down barely-literate workers is their goal, and so we should definitely strive to fight against that and the degradation of our craft.
Maybe we need a song to teach operator precedence. The PEMDAS acronym doesn't have the same lasting impact as the alphabet song it seems. Does Sesame Street feature any segments on arithmetic? I don't remember any from when I was a kid. Are kids who watch Sesame Street too young for that?
To be fair, this has a lot to do with the fact that C is pretty early in the alphabet, where it's easy to enumerate until you hit C before J. A lot of people couldn't say off the top of their head whether S comes before or after O, or whether R comes before or after V.
Making languages users remember whether + has higher precedence than | is 'unworthy' complexity, the only reason we have such things is that it simplified language implementation..
It's not obvious to most people what precedence to expect
Nothing is obvious to anyone who hasn't learned it yet. Where do you draw the line? The rules of a natural language are orders of magnitude more complex, yet humans have no problem learning and using them. There are twenty-six letters in the English alphabet, and "most people" wouldn't have trouble answering if C comes before or after J. Yet you look at the few more levels of precedence in this other language you use nearly every day, and "OMG too hard!!!!11" ?
It's sad to see this strange sentiment of "anti-intellectualism" or "anti-learning" that seems to be slowly growing in the programming community; and turning a linear one-dimensional ranking into a two-dimensional sparse matrix of comparisons seems like the exact opposite of a solution or reduction in complexity.