Yes but if in the past you could blame your internal developer for making slow SQL query, now these rich possibilities to perform really stressful queries to your DBMS are open to the public, right?
The main riddle to me is: in case of RDBMS in backend, how can we guess in advance which indexes are needed and how can we forbid/limit all "heavy" queries?
GraphQL has a notion of query complexity, that you can use to forbid certain queries.
Also, where appropriate, you can still gain a lot with caching.
Simple example: cache the query response containing all fields of a table, and extract the fields required for the response.
Many people smarter than me do think that caching [SQL] queries proved to be really bad idea (regardless of DBMS). Why caching API queries would be better?
Even if I would use query caching, I cannot imagine how it would help me to deal with really long queries (say, lacking proper indexes). Caching doesn't help when your query runs for 30 seconds – nobody will wait (and produce cache for others) so long.
Just as a relational database itself can sometimes generate better query plans from its query analyzer if you feed it what you are really after in one big, slow query that narrows to very specific rows rather than lots of small queries that return lots of rows quickly. Amortized against the database's time (CPU, memory) and bandwidth that slightly slower query is still sometimes a big win for overall performance.
(Given that most GraphQL services are typically backed by relational databases, it should probably not be a surprise the savings sometimes get passed right along.)