Referencing:
So first the inefficiency explained. Auth rules work by checking for the existence of the inner fields which under the hood uses the same process as @cascade so if all fields requested in the rule exist then it equates to true.
But @cascade is inefficient because it is a post query process in the query plan. There is a query plan even though there is no query planner at the moment. This is just understood that the query always follows the same plan, maybe some day we will have a DQL query planner that will make this better. See for reference: Query Planner. Back to the topic at hand. The main problem with cascade is that you could have a rule that queries ALL nodes of a type with deep edges to appease the rule, when more efficiently would be to write the most efficient query to get a truthy value.
In example:
Data:
_:foo <dgraph.type> "User" .
_:bar <dgraph.type> "User" .
_:baz <dgraph.type> "User" .
_:foo <User.status> _:status_1.
_:status_1 <dgraph.type> "Status" .
_:status_1 <Status.status> "1" .
_:status_1 <Status.for> _:foo .
_:bar <User.status> _:status_2.
_:status_2 <dgraph.type> "Status" .
_:status_2 <Status.status> "0" .
_:status_2 <Status.for> _:bar .
_:status_2 <Status.for> _:baz .
Take these triples and imagine we had a few more million users to go along with it, but only these two status nodes. If you wanted to efficiently query the users with the status equal to 0 you would not start at the users, traverse to the filtered status and then post query process to filter those users out. No, instead to be efficient you would start with the smallest universe which would be the filtered status and traverse to the users, and then use those users to appease the rule.
This really gets nitty gritty though because depending on how in GraphQL you filter your query and depending on the data layout, this might actually be less efficient.
So again I reference the link above to the query planner if you want more of my thoughts about the complexity of actually making queries more efficiently which depends on the data, and how do you know the data until you make the query. 
