That’s exactly what I’m saying. Neither REST nor any other query language is an API. A query language simply can’t provide any form of resolver, it just tells you which data is available and what form this data has. This has nothing to do with believe - at least in my opinion. If GraphQL (or REST, …) would be an API, you could also say that Python, PHP, Node, … is a server because you can have a Python server, PHP server, etc.
And this is where (at least for me) the problem lies if you try to put too much logic into a (in this case GraphQL) query language. That’s simply not the idea of GraphQL.
However, I think I understand where you coming from and I guess we mean the same thing just have different semantics. 
True, he did not say that and I have to admit, that I haven’t dug into the code deep enough to argue against it. However, since we are basically writing queries in @auth and since everything gets translated into DQL on the Dgraph side, I could imagine that the auth queries are part of a query block. I guess when protecting a query, it can definitely be parsed and added as an additional filter, for mutations it will probably go in the query block of an upsert mutation. In both cases it’s something the server needs to evaluate before it returns the main query result - however the server does it in the end. But as said, there might be some very sophisticated things going on I simply don’t understand.
Have a nice week!