Implementing SIP a couple of times, part of it is the other implementations just flat-out misread. Even when there's a formal syntax specified, they simply ignore it. For instance, SIP specifies a "lr" (loose route) parameter. The syntax is just that: lr. But many implementations get it wrong and require a value, like lr=1, or lr=true.
Even things as simple as line endings are implemented wrong (in HTTP too), and that can cause security consequences as proxies end up reading headers differently than the user agents. I've seen this live on the public Internet.
SIP and the IETF to some extent encourages this with Postel's Law, telling implementors they should guess what the intention of the message is. We need less of VB's On Error Resume Next and more panic-abort type functionality. Look at this insane document: https://tools.ietf.org/html/rfc4475 "SIP Torture Tests". The authors gleefully come up with ridiculous yet legal permutations of messages that are allowed under their arcane rules. The fact this exists should send the opposite message: simplify your damn protocol. And this is only at the parsing level!
I know people say that HTML could never have had strictness because it'd have been too hard, but I don't buy that. One common issue was getting nesting wrong, like or leaving unclosed tags. By removing the (silly, honestly) name out of the ending tag and just using , a whole class of errors is removed. Add in a browser that just fails to render and explains exactly why, and people would quickly not publish pages that are broken.