That's an interesting point. The beauty about SQL is that behind it, it has really good backed theory of Codd's Relational Algebra. Whereas Document Based, Column Based and GraphQL, don't have that. It would be interesting to see research on Graph theory as data sets and how to represent them as a formal query language. The majority of Graph theory I remember taking in my CS classes (granted, that was more than 15 years ago) was about graph traversal and path-finding.
Eh, many REST endpoints are de-facto indistinguishable from RPC. Though as far as a general query language for Web clients, you can use SPARQL which interoperates well with REST principles.
Or use Odata: rest, with all the benefits of graphql, and aggregations, grouping, joins, filtering, sorting.
It's also torturing the definition of "query language." There is no equivalent of "join", or any other typical query feature such as aggregation, grouping, sorting, filtering. GraphQL has as much to do with graphs or query languages as my smart TV has to do with intelligence. It's RPC, but RPC fell out of fashion when SOAP/WSDL/XML died.