Postel's Law or the Robustness Principle

In computing, the robustness principle is a design guideline for software:

Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept").

The principle is also known as Postel's law, after Jon Postel.

In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.

source: Robustness principle (wikipedia)

This simple statement captures a significant concept in the design of interoperable systems. Many consider the application of the robustness principle to be instrumental in the success of the Internet as well as the design of interoperable protocols in general.

Time and experience shows that negative consequences to interoperability accumulate over time if an implementations apply the robustness principle. This problem originates from an assumption implicit in the principle that it is not possible to affect change in a system the size of the Internet. That is, the idea that once a protocol specification is published, changes that might require existing implementations to change are not feasible.

Many problems that might lead to applications of the robustness principle are avoided for protocols under active maintenance. Active protocol maintenance is where a community of protocol designers, implementers, and deployers work together to continuously improve and evolve protocols. A community that takes an active role in the maintenance of protocols can greatly reduce and even eliminate opportunities to apply the robustness principle.

source: The Harmful Consequences of the Robustness Principle (IETF)

In my opinion, the critical factor of the criticism is "protocols under active maintenance" and the assumption that "it is not possible to affect change." Most developers are trying to implement just one side of an established protocol and the task is simply to get the program to work and reduce its fragility. For this scenario, robustness is of benefit. For those developing protocols and reference implementations, strictness has the benefit of early detection of defects and ambiguous requirements.