To the former point, you’re saying it doesn’t make sense for GQL, I’m saying why fix what isn’t broken? Request level caching works great for certain needs. But I get your point that it doesn’t apply as directly for GQL and yes, people do have these needs also.
To the latter - at least with fetch, reading the response payload is a second blocking call after running the initial request. You can read the status with one less method. Amazing argument for pre-optimization? No, I get it, but it just feels like more overhead in practice to me at least.
I think the point has been made clear to me that there is definitely one or more use cases that GraphQL solves for better than REST, and it is still right to pick and choose the right tech for each specific job as it fits best.
And if you're reading the error details from the payload anyway, why bother with setting the error code when it has another, request-level, meaning?
Not sure how any of this proves GQL is a premature optimization when caching could just as well be considered a premature optimization.