This is the essential difference between neo4j (a property graph engine) and most RDF stores which support quads (i.e. <subject> <predicate> <object> <context>)
If A and B share an event via a friendship, you can keep track of things about that. Granted in an RDBMS if all you wanted was to draw the line then you could do it with an extra FK, but I think the conclusion you're drawing is going too far, specifically:
> In SQL that wouldn't have been a remodel, because there's no difference between a relationship and an entity
There is a difference in SQL; relationships are EITHER more columns, OR a join to another table, both are possible. In graphs, "hyper relationships" (e.g. relating more than 2 things) require another node, but this is apples/oranges comparison.
I hope something like this becomes as mature and usable as Neo4j.
For example: (:Person)-[:BEFRIENDS]->(:Person)
If we'd want to store a date with that relationship, Neo4j got your back, that's entirely possible (= relationships can have attributes). But now our requirements change and we'd also want to have an entity for Events shared by friends (e.g. friendship anniversary), now we have to remodel our data to something like:
(:Person)-[:IS_IN]->(:Friendship)-[:HAS]->(:Event)
In SQL that wouldn't have been a remodel, because there's no difference between a relationship and an entity. We would've gone from:
Person(id) Friendship(person1_id, person2_id)
to:
Person(id) Friendship(person1_id, person2_id) Event(friendship_id)
So I feel like the vertice/edge distinction Neo4j makes, gets in the way of changing data model needs and I ultimately think that modeling your data as a graph is not helpful. Though it can be extremely helpful in querying and that's where its biggest strength lies.