Evolex_,

наверное это продиктовано спросом, т.е. его отсутствием, т.к. очень мало кто упирается
в какие-то специфичные ограничения, разные инструменты для разных целей.

получается смысла особенного искать разницу нет - кроме каких-то экзотических use case

(т.е. не получить существенную пользу от затраченного на это времени,
есть более выгодные альтернативы инвестирования усилий в изучение других нюансов технологий)

Evolex_,

так ведь всё как всегда через здравый смысл и концепции/принципы,

если это масштабная мера (все ей пользуются) эффективно реализуемая на уровне хранилища - то зачем её каждый раз считать на клиенте
если это ресурсо-затратная экзотика нужная одному пользователю, но нет особого смысла специально для этого делать объект в источнике
кроме того есть вещи которые легко реализуются в DAX и немного сложнее в SQL, так-же наоборот: легче SQL или через жж в DAXe.
для расчёта одного скалярного показателя не всегда имеет смысл тащить гигабайт данных на клиент
(если это только не обвешано кучей динамических self-service контекстных фильтров на клиентском интерфейсе)

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

остальное по предпочтениям/приоритетам/политике/способностям, на вкус и цвет в общем, ну и по ресурсам/масштабированию
конечно - у нас пока один MPP/DWH был: больше делали на клиенте, как пиковая нагрузка выросла до 200-300 пользователей
- так докупили нодов Azure DWH (кроме динамического DWU: даже подняли ещё instance с LoadBalancing под разные нужды)
(в принципе если управлять нормально peak/offpeak - то по расходам приемлемо получается: никто копейки не высчитывает)
а в остальном расчёты чисто денежные: ресурсы, производительность, стратегия, будущее, гибкость и риски.

для разнообразия: между SQL и DAX +модель - ещё ведь и M присутствует,
я на нём иногда до половины преобразований/расчётов делаю,
в прототипных целях чтобы не заморачиваться.