Моделирование базы данных в Neo4j

Один из основных ответов на этот вопрос завключается в том что графовая база данных будет иметь более высокую скорость работы на больших (или очень больших) объемах данных.

А иначе резона нет.

Не только можно, но и нужно! Графовые движки лучше использовать для работы уже с построенным графом тк он это умеет делать быстрее

Графовые БД хороши для представления данных, которые по своей природе выглядят, как, извините, граф (ну или дерево).
В случае попытки представления дерева в "реляционном" виде, в процессе нормализации, строки таблицы пополнятся избыточной информацией: например, в случае представления даже дерева (более простой вариант графа), строкам в реляционной БД будут соответствовать пути от корня до листьев (я тут упрощаю, конечно) - часть атрибутов в строках будет дублироваться (то, что ближе к корню), а часть наоборот будут пустыми (пути корень-лист разной длины).
Если же решим проблему избыточности разделив таблицу на кучку красивых-отдельных, соединив их по ключу, то при попытке получить изначальные данные в виде строк корень-лист получим значительный оверхед на join. Т.е. такие запросы будут долго выполняться.
У графовой же БД отсутствует оверхед на join, если сравнивать с реляционной БД. Ну там, конечно, больше и плюсов (и минусов тоже), но эти сразу на поверхности.

P.S. Кстати неплохая, кмк, графовая БД https://dgraph.io/

Основная проблема "реляционок" в том, что связи/реляции (как это не парадоксально) в РСУБД отсутствуют - реализация основывается на АССОЦИАТИВНОЙ модели (связи строится в join), связи не материализованы и возникают в ходе построения плана. План строится "на-лету". В графовой же БД связи материализованы и опираются не на ассоциацию атрибутов сущностей (термин нормализация присущ РСУБД), а на прямые указатели конкретных вершин. Это подтверждаектся тем фактом, что РСУБД критичны к CPU, в то время как графовые СУБД сильно зависят от оперативной памяти.