Syrus is correct that it will have about the same performance as Node in these particular benchmarks.
We are working on performance improvements for Apollo Server 2.0, but they are targeted at a totally different use case. Our experience working with hundreds of companies using GraphQL in production has indicated that the CPU execution time of the query is almost never the bottleneck when it comes to GraphQL.
The real thing you want to watch out for is the time it takes to call underlying APIs and databases, which will absolutely dwarf the actual time spent in the CPU. In this case, Node's non-blocking architecture helps a ton, and taking any action that prevents repeated calls (like basic caching) is critical.
In AS 2, we're going to introduce some features that make caching underlying data calls even easier, which we think is going to have the biggest impact on people's response time with GraphQL.
It's the same kind of thing as Express.js competitors showing that their routing logic handles 50k requests per second instead of Express's 25k, but only for "simple" use cases—AKA ones that don't involve a database. You should almost never be evaluating a server on these parameters.
However if you think it will be useful to compare against, I will be super happy to accept it as a PR in gbench: https://github.com/graphql-quiver/gbench