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

Далее, как только будет необходим шаг вправо/влево, что-нибудь не предусмотренное фреймворком, ничего не останется, кроме как обратиться к разработчикам фреймворка => отсюда лишняя зависимость от сторонних чуваков, их занятости и заинтересованности. Заинтересованность скорее всего придется банально покупать. Так не проще ли платить своему же фронтендеру, сидящему за соседним столом?

Далее, фреймворк предполагает, что бэк-разработчик, помимо своей основной специализации, также владеет как минимум HTML и CSS, а также понимает, в какой аналогичный JS-код выполнятся все эти DOMXxx()-вызовы. Что, очевидно, далеко не всегда так. Если скомпилировать все веб-стандарты (фронт-онли) в единую книгу, получится талмуд, на порядки толще стандартов для целых операционных систем. Поэтому я бы не говорил про отсутствие потери качества.

Далее, постоянно приводится пример, когда работает всего "один специалист": "работу можно выполнить одному специалисту одним инструментом" — в связи с этим фреймворк выглядит как временное решение на самом старте бизнеса, от которого постараются избавиться, как только у компании найдутся деньги на найм фронтендера.

Далее, для фреймворка такого типа выбран странный транспорт - XHR, когда как веб-сокеты не предполагают переподключения на каждый чих (а чихов будет много -- реакция на гуйные события как-никак). Можно же задействовать XHR в качестве фолбэка в конце концов.