First an important clarification: The robustness principle only applies to ambiguities in a protocol specification.
It is sometimes confused which having flexibility in acceptable input - for example JavaScript having optional semicolons. But JavaScript semicolon insertion is specified in detail in the ECMAScript standard. Whether is is good language design is a separate question, but there is no ambiguity in the specification and therefore no place for the robustness principle.
The principle does not allow you to go against a specification. For example a JavaScript parser is not allowed to accept common misspellings of keywords. The spec is unambiguous about spelling of keywords, so that would just be invalid.
This lead to the conclusion: Having a detailed spec which covers all eventualities is always the most robust solution. If you are designing a protocol, you should take care to avoid ambiguities in the specification.
HTML initially did not specify how to process invalid HTML which lead to a number of incompatibilities. But in HTML5 the processing of invalid HTML is also specified so this eliminates the need for the the robustness principle.
When you are designing a library or API you decide on the interface yourself, so the principle is not relevant. It is only relevant when integrating with component you have no control over.
But in the very specific case where you are implementing a protocol with ambiguities in the specification, I will argue the robustness principle is common sense. Just don't apply the principle outside of this context.