Your argument makes sense but it does require a lookahead of two tokens in the parser which may not be commonly implemented in Prolog parsers. I guess SWIP is one of those that doesn’t:
And I might be wrong but I think the ISO standard states that Prolog syntax be parseable with an LL1 parser.
Another data point from Eclipse documentation:
A.3.3 Operator Ambiguities
Unlike the canonical syntax, operator syntax can lead to ambiguities.For instance, when a prefix operator is followed by an infix or postfix operator, the prefix is often not meant to be a prefix operator, but simply the left hand side argument of the following infix or postfix. In order to decide whether that is the case, ECLiPSe uses the operator’s relative precedences and their associativities, and, if necessary, a two-token lookahead. If this rules out the prefix-interpretation, then the prefix is treated as a simple atom. In the rare case where this limited lookahead is not enough to disambigute, the prefix must be explicitly enclosed in parentheses.
Another source of ambiguity are operators which have been declared both infix and postfix. In this case, ECLiPSe uses a one-token lookahead to check whether the infix-interpretation can be ruled out. If yes, the operator is interpreted as postfix, otherwise as infix. Again, in rare cases parentheses may be necessary to enforce the interpretation as postfix.
When a binary prefix operator is followed by an infix operator, then either of them could be the main functor. Faced with the ambiguity, the system will prefer the infix interpretation. To force the binary prefix to be recognised, the infix must be enclosed in parentheses.
Just a few indications of the state of parsing user defined operators in Prolog. So you shouldn’t be surprised by a few anomalies, particularly in the area of postfix operators which don’t seem to be used a lot.
If you’d like to help sort it out, SWIP is an open-source community 
.