Если вы учитываете расходы электрической энергии погрузчика на доставку каждого конкретного заказа, из пункта хранения склада А в пункт Б — С — Д — (там может быть сформирована цепочка), учитываются трудовые ресурсы «Грузчик Иванов тащил 15 минут двигатель ЯМЗ сер. номер ...» и т.д. равно как вы выписываете путевой лист на конкретную доставку товара со склада А в склад Б (пробег, расход топлива), командировочных расходов (склады в разных городах), то наверное разницы нет.

0) Внутри нет, но партии разные с разной себестоимостью и какие партии пойдут по накладной перемещения согласно бизнес-логике WMS
1) Во вторых то что склад это отдельная группа зданий это ваша гипотеза, которая в реальной жизни может и не реализоваться. Я вот к примеру наблюдал реализацию, когда ЕРП система видя (WMS подсказала), что на основном складе не хватает части товара автоматически сформировать связанные документы на подвоз из других складов и документ отгрузки клиенту по факту обрабатывали 3 разных склада (разные партии, разные себестоимости транспортировки/ хранения по понятным причинам) с 2мя типами WMS один из которых склад-аутсорс.

"… А в вашем случае как дооценить поддон, если вы его обсчитали на стороне?..."
Более того если склад у вас большой (или вообще на аутсорсе) и им рулит WMS, в документе ЕРП будут позиции сгруппированные по номенклатуре, далее вы пошлёте их в WMS и она даст вам реальное товародвижение (какие партии пошли по вашему документу).

Яндекс в качестве oltp базы не так давно начала предлагать вот это: ru.bmstu.wiki/Yandex_Database
но:
0) она, ИМХО, сырая ещё
1) там весьма суровые ограничения

Что значит «закоммиченом»? Документ лежит в базе, его может посмотреть начальник менеджера («Чем этот балбес занимается весь день?»), по нему строятся отчёты на предмет как идёт процесс работы с закупками (менеджер ведь не одной этой поставкой занимается), по нему можно посмотреть историю изменений и т.д. и т.п.

10 секунд на выборку по списку документов для любой выборки по списку документов это не просто долго, это безумно долго. Вот недавний случай «из жизни»: есть 250 «точек» которые грузят клиентам «что-то» (предположим что таблица у нас всего одна «Заказы на отгрузку»). До недавнего времени «точка» список своих документов на отгрузку обновляла примерно раз в минуту (взяли товар, отдали клиенту, показали, выбили чек). Положим у нас 40 ядерный процессор на СУБД выделен (по факту на месте стоял более слабый) и памяти хватает, чтобы табличка целиком лежала в памяти. Таким образом имеем (грубый подсчёт), получается что 60% процессорного времени (10 расчётов в минуту, укладывались сканом в 5-6 секунд на ядро * 40 ядер) СУБД будет поддерживать только эту операцию — выборки списка документов на «отгрузку» для каждой точки (в реальности больше, т.к. тут задачи на расчёт для простоты не мешают друг другу и не ждут ничего, а культурно раскладываются по ядрам последовательно). «Примерно так» и было в действительности «на месте» до ухода «в индекс».

"— необходимость обновлять все индексы во всех связанных таблицах при каждой транзакции
— необходимость предоставления многопользовательского доступа к данным"
Не все, а только индексы для полей, которые участвуют в изменений обычно, (хотя если в вашей ERP, к примеру, тупо без разбора обновляются все поля документа при изменении статуса его, то это ваша «прикладная» печаль).
— Раз тут Вы упомянули о MS SQL, то там есть optimistic locking и inmemory database

«random read это дорого, не спорю, поэтому и фуллскан.»
Фулл-скан всегда это очень дорого, даже если табличка помещается в памяти — ядра ЦПу будут только и заниматься тем, что перелопачивать десятки миллионов строк (больше не видел на OLTP базах, мы ж о ERP говорим использования «такой схемы», обычно колом становится раньше )

Если мне память не изменяет, в Кликхаусе отсутствуют транзакции, что ставит на ней крест для использования в ERP для регистрации потока документов.