These systems usually have specialised on-disk data structures and algorithms (e.g. path finding) that are multiple orders of magnitude faster than the equivalent data stored “Flat” in a column database, this difference in time and space efficiency isn’t “some glorified academic project” - but the concrete difference between practical and impractical
I’ve been a developer with 18 years commercial experience now and I’ve seen graph databases in all size businesses as I’ve travelled the world, from 1-2 person startups to huge online casinos, heck, I’m a single person startup and I have two myself, one with 200,000,000 nodes and there’s no way a traditional database could do what that system is doing (I tried with Postgres, HBase on Hadoop, and Cassandra)
Sure they are not as common as traditional DBs, but they are far from niche, that’s why (as you said in your original post) there’s so many products in this space competing - they are actually a thing, they are actually useful, and for some projects, critical.
The IRS also recently contracted Brillient to "define and prototype a graph database for the individual taxpayer"[2]. This is supposed to "enable IRS researchers to visualize complex relationships to improve compliance and enforcement."
[0] https://www.irs.gov/pub/irs-soi/09rescongraphquery.pdf
[1] https://www.aaai.org/Papers/Workshops/2005/WS-05-07/WS05-07-...
[2] https://www.brillient.net/news/brillient-awarded-new-task-or...
Graph implies lots of nodes, which means lots of data. Only certain businesses use lots of data. Most small/medium businesses won't use it. That's why it seems like graphs are mostly in use at big tech etc.
GraphQL can also run on traditional SQL databases, but I think at some point they hit complexity limits and performance issues because JOINs are hard for them, especially if the columns aren't indexed. In a proper graph database, relationships are first-class parts of any data model and there are no "tables" to speak of, just nodes and the arbitrary, complex relationships between them. It makes data modeling both more intuitive (if your data is naturally a graph) and more performant. Here's one take on it (https://developers.mews.com/intro-to-graph-databases/)
At the end of the day there is no magic cure-all for data storage. It depends on the data you're storing and the way you need to read and write from it. And business wise, it may not be worth it to rewrite 10 years of SQL databases to improve performance by a few percent. But if I were starting a new project from scratch, one that involves layers of interconnected data (say, a bookstore with connections between books, images, authors, customers, reviewers, reviews, inventories, third-party merchants, Goodreads entries, different versions for audiobooks and ereaders, multiple books in a series, etc.) it's the kind of thing that would lend itself well to a graph database in modeling, as long as the stack can also be performant and scalable enough for end users.
As a web dev "in the wild", we've offloaded the scaling problem to a vendor by choosing to use a headless CMS (GraphCMS, DatoCMS, Contentful, Prismic, etc.; there are many). Some of those use graph databases while others don't, but at the end of the day we don't really care as long we don't hit their complexity limits. They play DB admin, we get GraphQL or traditional REST APIs, and we can build a frontend on top of that.