If you control the back and front end, I don't buy into this argument. You don't have to define all your REST endpoints up front, you can add them as needed.

If you're serving a public API and you really don't know up front what endpoints people will need, or like facebook you have tons of people with different needs, then maybe GraphQL makes sense.

When you have separate backend and frontend teams, Conway's Law starts to rear its ugly head. GraphQL can help smooth over some of that organizational friction and maybe keep the frontend team from making N+1 requests because they gotta get this feature out by the end of the sprint and backend's busy with its stuff. They tell themselves, "It'll be fine. It's performs acceptably on my machine with my company internet connection."

And how often do you need that sort of decoupling at all?

Beside that, I disagree in principle because, like the OP said, it's just hiding the maintenance burden elsewhere. It doesn't go away.

The problem is the server has a connection to the database that’s infinitely more reliable than the client -> server.

I’ve dealt with garbage REST APIs with tons of sequential calls and in low reliability scenarios 1 call is a massive improvement over a scenario where 4-5 sequential calls need to be made and if/when one of them fails you need to start over.

Now the client has to handle result caching and all the different error states because some server dev couldn't be bothered to batch a few calls and return all the required models.

At my company, we benefit from loose coupling between components every time we'd like to release an update to one without a concomitant deploy to some other service.