不管是什么技术，总有个适用范围。没什么东西是万能的。
GraphQL 的语法也好，ElasticSearch 的 Query 语法也好，SQL 也好，本质上都是一个用来 Query 较复杂结构的 DSL。你如果把整套 Graph QL 抽象为接口，那么你认为你是在前端写 SQL 也没有问题。
但 GraphQL 主要是用来解决 API 设计问题的，至于怎么优化查询并不是它的重点。SQL 本质上也是一样，这种语言是设计用来查询关系型数据的，怎么优化是 DBMS 的事。
REST 接口实现简单，也没什么复杂的心智负担。但如果你需要做成 REST 的东西比较多的话，前端免不了做一堆的 Promise 来回的查。而且这种多次查询后台也没法做优化。
你给每个需求写个 API 可以做到细致的优化，但是前后端很难同时开始工作，你得先定好接口，Mock，或者上 Swagger。而且这种写法扩展性有限，新增需求很多时候你就得新弄个 API。
GraphQL 和 ElasticSearch 的 Query 比较类似，优点不在于优化性能，而在于更大程度上去释放系统的可扩展性。比如你要做个类似 Kibana 的工具，绘制的图像各个轴可以自定义 model 和 field，但不涉及特别复杂的计算聚合和优化。那么类似的东西就是最好的选择。
真正使用的时候还是要根据自己项目的特点去选择合适的技术，不是看什么新就用什么。GraphQL 也有一大堆的缺点，但是你的需求如果可以正好避开这些缺点，同时它擅长的东西也是你想要的，那么没什么理由不用它。