Сам принцип звучит примерно так:

Будьте либеральны в том, что вы принимаете, и консервативны в том, что вы отправляете.

На поверхности звучит логично, и, пожалуй, он неплохо применим к пользовательскому вводу, однако в долгосрочной перспективе этот принцип скорее вредит. Даже в самой википедии есть критика, но подробнее и с примерами можно почитать в этой заметке, размещенной на сайте интернет-стандартов, в контексте которых и зародился принцип. А еще недавно появилась статья с еще одним наглядным примером про куки: сочная дичь, которая получилась как раз из-за недостаточной строгости.

Если вкратце обобщить источники выше:

  • Если что-то “почти правильное” принималось без проблем, то оно может стать де-факто стандартом. Потом будут сюрпризы при использовании альтернативных реализаций, особенно если у них разный уровень толерантности к вводу. Похожая фигня случилась с URI/URL. Из-за этого возможно придется делать совместимость на уровне багов.
  • Нечеткая интерпретация спецификации может привести к уязвимостям и другим проблемам безопасности.
  • Толератность приводит к усложнению реализации: будут разные модели для ввода и вывода, ну и в целом надо будет поддерживать дополнительный код для исправления неточностей, количество которого потенциально может расти со временем для обеспечения взаимодействия с новыми реализациями.
  • Многие упускают аспект, что этот принцип нужен для исправления недостатков спецификации, но часто есть возможность улучшить саму спецификацию.
  • Если не глотать ошибки/недочеты, то их будет проще обнаружить, и будет обратная связь для протокола/спецификации.
  • Работать обычно проще с меньшей вариативностью, KISS и все такое.