Not really. The type of API where you specify what you want and the API itself included whatever data you need in an RPC fashion has been around for decades, I feel weird calling it a "graphql api".
Ultimately GraphQL gives you some tools. The developer just has to figure out if those tools make up for the additional overhead (processing, size, training, etc). Sometimes it'll be justified I just think more often then not it really isn't.
You can roll your own version of the concept, but why bother when a perfectly serviceable one already exists? With already written client & server implementations in your language of choice?
GraphQL is indeed not a new invention. It's a standardisation of existing ideas, that has been given a particular name, and a whole community of people who are building tooling around it.
If you tell me you are using/implementing GraphQL then I immediately know what to expect. I know which tools I can use, I know you have a schema, I know I can run queries and the syntax of those etc. But if you tell me that you are using a REST/HATEOAS/RPC with some particular query syntax then I first have to spend a day reading through the documentation to understand the API.
i think you're giving graphql too much credit, and give too little to REST.
The schema of graphql is going to require just as much reading up and domain knowledge as the REST api.