You're assuming that they can control the clients behavior easily. In our company, we have a large infrastructure of GraphQL services that talk to each other. One client may be .NET code, one may be javascript, we even have python code. Changing the format of responses would require us to review each of these different pieces of code scattered throughout our various codebases. Any tests we've written that validate the returned status code may need to change. Since we are not exposing GraphQL to the public, compatibility with the GraphQL over HTTP protocol is not a concern. And if we had a public API, it would be important to maintain behavior of the endpoint throughout the supported version of that API. I've always had our servers return 400 for validation errors, and I expect that to continue.

It is also important to note that Apollo GraphQL server behaves as if this option were false by default, always returning 200 for validation errors (which are not transport errors). For compatibility with other servers alone, we may want to keep this option.

I really don't see any reason this isn't a valid and normal configuration option for the server project, just like changing the default content type returned, enabling/disabling CSRF protection, or enabling/disabling form parsing. Keep in mind that it's just an option, and it's configured to the recommended default per the draft GraphQL over HTTP spec. (The spec isn't even finalized yet!)