Additionally; GraphQL never got the community love it needed on the backend side to make things hum. Apollo is the only organization really pushing it, and they invest something I'd estimate as 10% of their time into thinking about Apollo Server, which is in any event JavaScript-only. It turns out, the problems GraphQL creates in a system are backend problems; there's some really freakin hairy edges in the domains of authorization, caching, rate limiting/complexity limiting, even just basic type safety, that can only charitably be described as "solved" if you consider "some ideas in a twenty page blog post" as a solution.
We also had constant problems educating our customers about GraphQL. "No no, you can use any REST client you want, here let me show you how to set it up" (two hour education session later).
There really isn't a perfect solution to the problem space. If your view is complex enough, synthesizing it JIT in GraphQL is just the frontend saying "its your problem now" to the backend, and whether the solution to that is "fixing performance bottlenecks" or "a new RESTful-ish view API for this screen" for the backend team, its still a ticket. If the view is less complex than that: making multiple requests isn't the end of the world. After all, those two highly predictable, optimized, even cached requests may end up being faster than one dynamic and extremely-difficult-to-cache GraphQL request.
At the end of the day, I think there's a reason why REST has lasted as long as it has, and why it still feels state of the art to me. Moving more API capabilities to edge platforms, including edge databases, shortens that string of beads quite substantially. Server-side rendering is back is in full force. There's other angles this problem is being attacked from.