Definitely, I can see that perspective.
There are some clear use cases where the benefit is quite obvious - for example if you’re interested in mapping out the user journey and some kind of non-simple path analysis, that’s a huge pain in a columnar structure, but graph makes it quite manageable (especially if there’s a non-linear path through your product - eg a signup flow is usually a manageable a>b>c>d, if you’ve got a path that’s a>b/c/d/e>b/c/d/e/f>etc. then good look modeling it in traditional SQL).
It’s interesting because there’s quite a lot of interest in graph DBs without widespread uptake yet (or at least without many people shouting from the rafters about their use cases). My hunch is that this is down to the fact that the first thing you do isn’t usually the use case for graph (the example above is something you wouldn’t want to do until you know a lot of other things about your product). I often wonder if that’s down to graph being more suited to late-stage analytics, or people’s experience/comfort level being more aligned to columnar.