GraphQL has some impressive points, but sometimes feels like it shifts too much control to the client. I'm on the fence about it.
There are performance footguns (like recursion, for which you'd have to consult your GraphQL server library for mitigations).
There is often a built-in 'introspection' endpoint, which many consider a security faux-pas (to which I disagree — I think it's pretty noble, like having built-in OpenAPI docs) BUT you can easily craft a recursive query using just this endpoint that will take (some) GraphQL servers down.
There are plenty of posts written on the matter and I'm sure there are mitigations, but my first exposure to GraphQL was on someone else's project (a respectable engineer who I consider very skilled) and within the first day I had noticed this intriguing structural hazard and taken the server down...
It therefore seems to be a tool that is possibly difficult to 'hold correctly'; at least people should be cautious about going in without doing their research about these things.
Probably a maturity issue, but one that people ought to be aware of?
Other gripes:
It's displeasing how the HTTP status code does not correlate with the actual success response of the API, which makes typical request logging less useful.
I guess it also makes it harder to provide optimised hot paths on the server (because your client team might shift their queries around, or whatever).
In previous experience I also find that having easily-recognisable names for API endpoints (like `GET /repositories`) makes talking about them, and recognising them, easier than the more-opaque-feeling GraphQL approach.