It is an RFC, and these tend to be about network protocols…
HTML <= 4 used to follow this principle, and turned out to be a non-interoperable mess. It needed an intervention in the form of HTML5. Although it may seem that HTML5 embraces the robustness principle, it's more of a workaround for it: it exactly defines how to handle any input, even "garbage" one, leaving implementers no room for flexibility, so there are no undefined inputs left to be liberal about (XHTML is also defined for all possible inputs with no ambiguity, they only differ in what they prescribe for handling of the "bad" ones).
Non-network things decay too. For example, there's no useful spec for GIF. Real-world files depend on specific bugs, like misinterpretation of frame rate or spec-incorrect handling of backgrounds.
Browser interpretations of HTML are a indeed a hot mess.
However, HTTP and HTML tend to grow together.
By assigning new ports to HTTP/2 and HTTP/3 (and the versions of HTML that are prevalent at the time the protocols are released), older browsers that are not receiving updates would be completely unaware of the new ports and would only connect to the ports used for older versions where the clients would happily exist in their "I'm going to interpret things my way" world.
When connecting to the new ports, browsers would have to agree to abide by the new well-defined and strict specifications.
As support for HTTP/1 (and the associated older versions of HTML) disappeared, the HTTP/1 servers would either be shut down or configured to server redirects to the HTTP/2 and HTTP/3 content. In the latter case, should the client continue to issue HTTP/1 request to HTTP/2 servers, the server would send a "Version not supported" message telling the client to upgrade.
Yes, and when your protocol is almost 30 years old and has most of the true quirks and edge cases ironed out because nearly everyone with a computer uses it - I think adopting a more strict approach can make sense.
That said - there's a reason this draft wasn't adopted: it doesn't make sense in most other areas (and certainly wouldn't have made sense for http and some of these protocols even 20 years ago).
The reality of technology is almost everyone gives zero fucks about how good your standard/protocol is - they want to use it to do something genuinely useful.
---
To summarize: The initial argument of this draft states "The posture this statement advocates promotes interoperability in the short term, but can negatively affect the protocol ecosystem over time."
My rebuttal is: Interoperability in the short term FAR OUTWEIGHS negative consequences in the long term, and should be prioritized for any protocol which has not yet seen wide and robust adoption.
HTML <= 4 used to follow this principle, and turned out to be a non-interoperable mess. It needed an intervention in the form of HTML5. Although it may seem that HTML5 embraces the robustness principle, it's more of a workaround for it: it exactly defines how to handle any input, even "garbage" one, leaving implementers no room for flexibility, so there are no undefined inputs left to be liberal about (XHTML is also defined for all possible inputs with no ambiguity, they only differ in what they prescribe for handling of the "bad" ones).
Non-network things decay too. For example, there's no useful spec for GIF. Real-world files depend on specific bugs, like misinterpretation of frame rate or spec-incorrect handling of backgrounds.