For example, Twitter pages not working if there is a fbclid parameter.
There are two main reasons that users might validly use unknown options. The first is that it's an option with valid semantics in different versions/implementations of the protocol. The other is that you're reusing an option block for many API calls, and some of the options may not be relevant for some of those APIs. For the first use case, erroring out (or at least warning) is usually the superior solution: you don't know what it means, so you can't guarantee that you'll implement it correctly. For the latter use case, ignoring can be a safe solution.
FWIW, there's been a pushback against Postel's Law (which is what the adage you cite is usually called) in more recent times. In particular, it should be emphasized that the law is generally most applicable when you're dealing with multiple interpretations of an ambiguous specification, and is least applicable when the standards are prescribing or proscribing particular behavior.
If the first web browser was extremely strict on the tags and structure it supported then web could not have evolved that way that it did.
Say you have an API that is documented to accept params A,B or C i.e /v1/api?A=1&B=2&C=3
What should happen if you pass a param D to it? i.e. /v1/api?A=1&B=2&C=3&D=4
The two most common schools of thought are:
1) Ignore D
2) Throw an error
Both present their own problems, esp. when D may be closely related to A,B,C. Interesting how API design also tends to side with personal preferences for strictness or leniency