(I'm the author.)
* Security; allowing evaluation rather than a describing results.
* DDL; Data Structure and Types need to be learned out-of-band. Ideally we want a sort-of interactive INFORMATION_SCHEMA over http, so our tools can inform us about types/structure and we always have updated info as we write queries.
* Performance; Stored Procedures (server-side) protect against a client making poor joins; ORMs requesting too much data, etc...
* Info about Security: client side SQL doesn't know what rights it has, or you could say that a client account can't see the big picture of DDL. The understanding of rights is all communicated through non-API means.
* Info about Performance: clients don't know rate limits, current system load, what system admins consider reasonable data sizes or reasonable analytic calculations, etc...
I don't know what GraphQL does for each of those issues, but I'd love to hear.
[0] I recently setup InfluxDB which has a (private) web interface that takes raw SQL-ish, and it's so convenient.
So for example, if you allowed "comments" to be queried within a "user", you'd make sure that users could be looked up efficiently by their ID, and that comments could be loaded in bulk efficiently based on user ID. You'd also make sure that your implementation for both those operations is secure.
It's not too dissimilar to REST in that you're still very much designing what your API should look like and not exposing anything else.
It creates a RESTful HTTP API out of your existing postgres schema. It practically eliminates the need to write a CRUD backend.
It turns out that most of what is usually expressed in implementation code assuming that you're hitting a dumb backend is just as well-served by SQL functions and schemas. This probably breaks down for larger projects, but it certainly has its place, and I can imagine something very similar be done for GraphQL.