As mentioned, the question of traversals vs joins are the key. You'll need to view this with an understanding of how efficiency will be impacted as the data within your tables grows, and as the number of joins increases.
RDBMS joins are at best O(log(n)) when indexes are present to support each of those joins, meaning that as you increase the number of records in the table being joined against, performance will eventually be impacted. But this is O(log(n)), so it won't grow by much, but in this age of big data and data lakes, we are increasingly working with larger and larger sets of data. The point is that the efficiency of the join is still based upon the amount of data in the table being joined.
With index-free adjacency, there are no joins when performing traversal, these are pointer hops, O(1). No matter how much many data is present, no matter how many nodes there are for the given label you are attempting to traverse to, the cost of the traversal of a node's relationships remains O(1), since we only have to look at this node's relationships, not all the relationships or nodes in the graph.
And if we're only doing comparisons for a single traversal, the differences between O(1) traversal and O(log n) joins are small enough to be trivial in most cases. But how many joins/traversals does the query require? Graphy problems usually require many traversals, sometimes an unknown amount, and where in a graph db this would be O(1) * number of traversals, for a relational db it's log(n) * number of joins, where the
ns all differ depending on which tables are being joined. That can add up.
Additionally there's the issue of how to specify the join conditions. If using vanilla SQL you would need to know more about the data in your db, how to perform the joins, which keys from one table are used to join to another table. In Neo4j a relationship between two nodes doesn't have to be based on any of their properties. We don't even need to access the properties at all. And for that matter, we can even traverse through nodes of different labels using relationships of multiple types. Or we may not care so much about the labels or types. In SQL this would be the equivalent of being able to join through any table at will, without knowing ahead of time which tables are being joined or how to join against them, or how many joins will be performed. I'm not sure SQL has such an ability to match that versatility. This is why graph dbs are good for discovering patterns or links between things when there needs to be a level of permissiveness and malleability in the rules followed to find those patterns (think Panama Papers, or analysis of Trumpworld finances, fraud detection, etc)
The caveat of course is that if your app doesn't need to make graphy queries like this, and it doesn't fit into traditionally graphy use cases, then you might not need a graph database. Relational dbs are fantastic for what they do well. But they are not a golden hammer, and their implementation can make them a poor tool to use for graphy use cases.