Well operational rollback usually means you return to your previous version. So if you add a new field to your schema, deploy, this is a compatible change. However if you rollback this schema to the previous version (remove the field), this is a breaking change.
You are right, the same problem exists with other APIs, but for example when we take REST, it is way more finegrained, and typically you can write your client code defensively to “adapt” those failures - e.g. missing field in the REST response, no big deal as mostly you can replace it with gracefully degrading defaults on the client side.
The problem with GraphQL in this case if your query might be spanning across multiple business domains as this is how it maps to the UI. With the REST calls, typically this would require multiple REST calls and if one of them would fail, you can still gracefully degrade the experience. However with GraphQL query (and out-of-sync incompatible schema), the whole screen fails and there is no way you can gracefully handle this situation on the client). Therefore I though what might be a good workaround is to allow the query to still perform, but response would signal back certain fields are not available (obviously that would work only for nullable fields) … I don’t think this breaks the strongly typed contract between the client and the server, but rather adds flexibility to deal with cases like that …