I'd agree with Andrew's general characterization of graph database advantages. Graphs are "whiteboard friendly" in as much as you can store data exactly as you would likely sketch it up when thinking purely in your domain. Because the graph structure is generic, you can even happily use it as a key-value or document storage. And, multiple intersecting domains can co-exist within the same graph. A graph could be a simple list, a map, a tree, or a complex network of data. With Neo4j, you'd get that expressiveness with the confidence of ACID behavior.
Beyond that, the Not-Only SQL options are a reminder to pick the storage that fits your application, rather than fit your application to the storage you have. Be domain appropriate.
I usually think in terms of:
RDBMS - when aggregating data is important
Graphs - when relationships between records matters
KV - when you have really simple data, but gazillions of records
Document - when you have complex, but unrelated and possibly non-uniform data
Beyond that, the Not-Only SQL options are a reminder to pick the storage that fits your application, rather than fit your application to the storage you have. Be domain appropriate.
I usually think in terms of: RDBMS - when aggregating data is important Graphs - when relationships between records matters KV - when you have really simple data, but gazillions of records Document - when you have complex, but unrelated and possibly non-uniform data
Cheers, Andreas