While it’ll take me more time to digest the entirety of this post, my knee-jerk reaction is that I could not disagree with you more. 
The whole point of using GraphQL is that its well-defined query structure maps precisely to an arbitrary graph space. In some sense you can think of a GraphQL query as merely the ‘simplest possible semantic representation’ of a traversal.
Why would you possibly demand an intermediate layer when the direct mapping can easily cover the data space? Most queries, even in complex apps, can be described by a single graph traversal. The queries that cannot are either outliers beyond my imagination, bad schema design that fails to appropriately model relationships, or filters that can be projected into a single query with slightly more ‘definition’ or ‘annotation’ on that semantic form.
Practically everything you suggest has outlier value and can already be engineered on top of Dgraph just as easily regardless of Dgraph hosting the minimal schema api. Of course you should be able to build an intermediate graph layer involving more business logic if you so choose…and there are totally valid use cases for things like validation, if you can’t rely on well designed data models or schemas. The whole point is that the Dgraph API ‘minimally covers’ the schema. But it’s added code, complexity, and ‘language,’ to traverse a system that is largely unnecessary for users with sound data structures (ie, 1:1 mapping between schema and data model).
In most cases, a modern client can simply be imagined as a portal for viewing and operating on a graph context. I don’t need any of the things you describe separated from Dgraph for my architecture that I’m confident can model practically anything I want to put on a graph and scale cross-platform to billions (Flutter + Bloc + Dgraph). Rather, you double my workload by forcing the separation, and drastically increase the business surface for errors.
Further, the things you advocate for separating have incremental value when built on top of GraphQL semantics. If you’re claiming that you can give me the same @auth flexibility without defining a duplicate semantic form that maps precisely to the schema…I just don’t believe you. Having the annotation in-schema gives me the confidence to deploy a single secure context that can be accessed by different apps with vastly different auth needs.
So I feel like this is separation-of-concerns gone wrong. I think a lot of the practical argument depends on imagining failure cases that Dgraph already solves for. And as a result, advocating for a migration of logic to the shoulders of the developer makes ‘engineering’ sense by following some arbitrary heuristics…but in this case I don’t think it leads to more elegant or more powerful systems. Dgraph is about user experience and maximized leverage, just as it should be.
If you can come up with some sound example schemas and views that you think require more sophisticated logical separation between the query and data layers, I’d love to give them some thought.