按规范做，是一种良好编程实践。
你可以指望你和你们的合作公司互相约好了“当你表面上说'不要'的时候，实际上你说的是'要'”。这时候不按规范是可接受的，沟通成本和开发成本都可控。
但你不能指望 github 开放它的 API 的时候和所有的潜在调用者做这样的沟通。于是使用现有共同认可的标准是最经济的做法。

但各种头本身就是一种“协商”机制。包括 content-type 协商，包括缓存协商。
它可以实现为“我期望最好是 xxxxx”，而不是“我要求一定是 xxxxx”。

例如，客户端可以写他请求 text/plain, application/json ，服务端可以实现为我尊重你的选择，尽可能匹配你的需求，如果找不到，fallback 到默认值 json 并返回。
这也为未来“可能”的扩展开放。
例如，昨天客户端说我需要 text/plain, application/xml ，服务端说对不起我只有 json 。
今天服务端进化了，提供了 json 和 xml 两种序列化方法，同样的请求今天就可以按用户需求提供 xml 响应。

至于这样的“扩展”会不会发生，也许这辈子都不会有。但至少它今天既满足了标准拥抱了变化，又满足了你 leader 的要求。