HTTP/2 doesn't fix the problem of loading data dependencies over a connection with a noticeable round trip latency. Even with server push, you need some way of defining what is to be pushed.
As a very contrived example, one page might show users who have access to servers in availability zones in aws regions. With an unnested rest api doing nothing intelligent with server push over a 250ms round trip, you're looking at a second of overhead just for sending ids back and forth.
Of course, there are ways of defining inclusion that are closer to restful than graphql is.
Falcor sort of solves this by allowing you to communicate "references" in the graph. For example, it might inform you that users.52.friends.1 is actually users.45, so the client will cache it at that location instead.
This is less complicated than GraphQL's solution of using the Relay Node interface.
That solves the problem of data normalization, not of determining what to fetch. Falcor solves the second problem with paths, but that's still a custom abstraction that the API has to understand.
As a very contrived example, one page might show users who have access to servers in availability zones in aws regions. With an unnested rest api doing nothing intelligent with server push over a 250ms round trip, you're looking at a second of overhead just for sending ids back and forth.
Of course, there are ways of defining inclusion that are closer to restful than graphql is.