Using a graph simplifies the query parameters, reduces the need for join() operations, and allows you to reason more directly about the data model instead of rdbms concepts and SQL. Could you do it in SQL? Sure, but the bolt browser and cypher made it go a lot faster. I'd go so far as to argue that graphs are optimized for reasoning and analysis, where relational dbs are optimized for performance.

When I need a performance problem solved, I'll hire an engineer to reimplement it, but until then, I can analyze the data at the business level. Right now I just need a rope across a river to see what's on the other side and not a bridge. :)

Aren't knowledge graphs just a buzzword way of saying "graph database"?

So yeah, the types of problem a db system solves are db problems, even if its using a semantic network model instead of a relational model

Graph databases can hold totally bespoke data that makes sense only to the consuming application or they can hold data that has been factored and connected to outside terminologies and external datasets. One holds data, one holds knowledge.

As i understand it, the graph nature of Knowledge Graphs allows simpler queries. And also a better moddeling of the data.

Some even support techniques like inferring "new" wisdome that was not implicitly moddeld.

In the end you could solve all that on other ways like making the application smarter and using a "not so smart" db system. But i am not an expert in that topic...