If you know ThePrimeagen on Twitter/YouTube, he worked on Falcor (the precursor to this GraphQL change) and he talks more about it [0].

GraphQL is very useful, it removes whole classes of bugs. You can even use a Result/Either type where if you don't handle both the success and error cases, the GraphQL request won't even compile, so you can get type safety at both the client and the server while also not having to use purely TypeScript like with tRPC, allowing multiple clients like mobile and web. Pothos does this very well as an error extension [1], where, given the schema:

    type Error {
      message: String!
    }
    
    type Query {
      hello(name: String!): QueryHelloResult
    }
    
    union QueryHelloResult = Error | QueryHelloSuccess
    
    type QueryHelloSuccess {
      data: String!
    }

you can then query it with

    query {
      hello(name: "World") {
        __typename
        ... on Error {
          message
        }
        ... on QueryHelloSuccess {
          data
        }
      }
    }

If you forget `... on Error` the query will simply fail.

I should also add that most people use GraphQL incorrectly, to get the benefits of not over/underfetching, the Relay approach using fragments is the only viable way currently. Otherwise it's not too much better than REST. You define the exact data required for a specific React component in GraphQL fragments, then the Relay compiler will stitch those fragments together into one and only one request. This is a great (if long) overview on the problems Relay solves and why everyone else uses GraphQL incorrectly (then complain that GraphQL sucks) [2]. Hint, Apollo is not the way.

[0] https://www.youtube.com/watch?v=yab6i9lrEv0

[1] https://pothos-graphql.dev/docs/plugins/errors

[2] https://alan.norbauer.com/articles/relay-style-graphql