As someone who used to write SPARQL queries for a living with some of the most established players in the Semantic Web game, the idea of SPARQL and GraphQL serving the same purpose is pure misconception (usually by folks who haven't yet taken the dive into GraphQL).
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.