То есть теоретически вроде понятно - хранение данных по трём измерениям, скажем, количество проданного товара в разрезе Фирмы, Склада и Контрагента.
С другой стороны в регистре 1С можно завести хоть 10 различных измерений, и что - это круче чем "модель куба"?
Зачем эта "модель куба" нужна вообще?

здесь рассматриваются многомерные кубы (т.е. они могут иметь больше 3 измерений)

(1) А зачем эти кубы нужны? Эта модель более удобна для восприятия чем "модель регистра" у 1С (назовём её так) или что?

(2) В модели куба нет детальных записей, там только итоги. А в модели регистра 1С сделана попытка в одном объекте (регистр) хранить и детальные записи, и итоги (таблицы, конечно, разные). См. также: http://www.mista.ru/tutor_1c/regs.htm

То есть, если я правильно понял всё вышесказанное, можно сделать вывод, что "модель куба является многомерной моделью представления данных (ерунда какая-то, если больше 3х измерений, то какой же это куб? ну да ладно), содержащая итоговые значения, каждое из которых соответствует только одному уникальному набору данных, заданных для кажого из его измерений". Так?

В терминологии OLAP, куб данных - это механизм, позволящий БЫСТРО получить
агрегированные (итоговые) значения по различным наборам измерений.
Для примера.
Имеем в 1С регистр с измерениями
Товар, Склад, Клиент,
и ресурсом Продажи.
Он хранит итоги по полю "Продажи" именно в разрезе
Товар, Склад, Клиент.
Куб данных же подготавливает информацию для быстрого получения итогов
по различным измерениям, и в идеале хранит посчитаные итоги в разрезах:
Товар, Склад, Клиент
Товар, Склад
Товар, Клиент
Склад, Клиент
Товар
Склад
Клиент
На практике все возможные итоги не хранятся. Часть расчитывается
при запросе. Отношение количества просчитанных заранее итогов
к возможному общему количеству итогов называют степенью агрегации куба.

КУБ - конструкция уникальной быстроты (по получению итогов)

(6) Лучше не "уникальной", а "удручающей"...