You are right about REST not necessarily replicating the N + 1 Query problem. ORMs have already provided solutions for this problem. See https://guides.rubyonrails.org/active_record_querying.html#e... for example.
Looking at GraphQL as being a media type for REST misses the point because:
1) If you were to build a system that primarily used GraphQL for communication, you would be breaking the spirit of uniform resource constraint. Since the URI is the resource for REST, you would be having exactly 1 resource. The article talks a bit more about this. 2) The value add from GraphQL is primarily faster (and more efficient) front end development. So the question is do you want to implement the GraphQL media type?
Typed vs non typed interfaces are a personal preference. Typing adds safety but historically made getting started harder. That has changed in the recent years though as tooling has significantly improved.
I've talked about sparse field sets in the article. They are an alternative, but any form of query language requires a parser and implementation in the backend and GraphQL has good tooling for this.
On the third point of N + 1 queries: Hasura compiles the sql query where possible and otherwise uses a batching technique for external APIs, similar to haxl.