Most of the time, in my app, resource names do not even correspond to single tables or backend data structures but are simply presented that way for ease of use for external consumers.
Subjectively, Implementing it feels more like old school COBRA than REST or SQL.
If I have to write something that’s REST-ish, I’ll do my damnedest to make sure it’s HATEOAS, but in my experience, the number of developers who can consistently produce useful and consistent HATEOAS APIs is…vanishingly small.
I can learn more about an API from its GraphQL schema than most of the other API documentation (like OAS/Swagger or RAML) out there.
Because relatively few developers truly understand HATEOAS let alone REST. I think that did play a small part in the increased popularity of GraphQL.
witness me!
GraphQL allows the backend to say "here's the data I offer and how it's structured, pick which fields you want from that" and the frontend query just specifies the "what." It's like picking from a menu (although fields can have parameters), and the results you get back are structured objects with nesting.
On the other hand, the data offered by a SPARQL endpoint has no inherent structure, the query is what gives the data structure. You not only ask what you want (the projection) but how to resolve the fields using (often complex) relational logic. It's orders of magnitude more powerful, which is awesome, but also more work and more confusing. Its biggest downside is that, like SQL, the results are row-oriented. For anything other than completely simplistic queries, the resulting data often needs to go through a transform/reducer step instead of being used directly, because real-world needs aren't always row-oriented (especially on the frontend). If you want to request information about both entities and the "children" of those entities, the projection is going to be (1) incredibly messy and (2) full of duplicate data, or you're making multiple queries.
I wouldn't want my frontend communicating with a raw SPARQL endpoint for the same reason I wouldn't want to expose a raw SQL endpoint (and basically nobody does). GraphQL puts the frontend "on rails" so to speak and lets the backend worry about the "how." That can be a positive or a negative depending on what you want to do, but in the frontend world (where REST is the norm), folks consider that a positive and it's the direction they've generally chosen.
On the other hand, GraphQL pushes its complexity (to worry about the "how") into the server's implementation. The complexity is still there. And it's impossible to be automatically browseable.
Semantic Web is only an application of SPARQL, not the only one.