Most graph databases could have just been simple SQL queries, often giving better efficiency and performance.
I have seen people use graph databases even when they do not need complex graph algorithms. All they need is to query by relations and perform some deep iterations. Fun fact - MySQL and PostgreSQL are perfectly suited for that.
If your query depth is known and bounded, relational databases handle it just fine with joins or recursive queries.
Graph databases often feels intuitive, but that does not automatically translate into better performance or simpler systems. In many cases, it is just overengineering.
They really start to make sense when traversal depth is unknown, queries depend on path patterns, or you need graph native algorithms like shortest path or centrality.
Rule of thumb - if you can express your queries with a fixed number of joins or a recursive query without pain, you probably do not need a graph database.