This is very interesting work. There is some selling going on, not discussing enough about the issues that drove the database community toward relational databases and away from "network" databases in the 1970s.
If you think of visualization systems as a microcosm of more general computing, notice people need more than graphs - they need all kinds of tables, charts, maps, and other things. Same with "graph databases".
This area does exist because the database community underinvested in computing on graphs and networks, the same as it did with usability for a long time. It is still catching up but there is a lot of great work.
Another problem is helping users to understand the cost of what they are trying to compute. Select and join? I can estimate that. Find betweenness centrality of a large network? Find a tour that visits all the cycles of a network exactly once? All the edges? All nodes? Oops. What about graph object types? Is it OK to mix them?
Sometimes I wonder arguments that "graph databases are [more] efficient for linked structures." After 20 or 30 years of intense R&D, relational databases already seem pretty efficient for computing with relationships.