The performance justification seems good, but it doesn’t apply in the case of GraphQL servers, which in my experience deduplicate the redundant fields on the server and merge the field subtrees in the response; it is then left to the client cache (Relay) to multiplex the merged fields in the response from the server back to the fragments with their redundant field specifications. So this capability in GraphQL is partly just syntactic sugar. (There is one real difference: when you request the same field more than once, each time with different arguments.)
(Relying vague memory on this; my recollection could be very wrong.)
I think I can work around Dgraph’s constraint, but I foresee possible corner cases in which the same fragment is embedded in multiple subqueries which will require some thought to aoid triggering this Dgraph error response.