Согласен, ибо, как обычно - истина посередине.
В начале топика, показал что и сколько стоит в PHP. И как ни крутись, а интерпретатор так и останется интерпретатором. И, чтобы искать эту "золотую середину", кмк, стоит помнить о "цене вопроса", в т.ч. и с этой стороны - условного КПД интерпретатора.
Вы же "полистали учебник", верно?
Давайте по пунктам (прошу прощения за много букв):
1. Настройка фреймворка на Приложение.
Нам надо "внедрить зависимости". В Kohana, этом USSR, и др. простых решениях, разрабу предлагается по сути один способ и "самый простой" - включить нужные файлики в нужном месте до запуска роутера (диспетчера и т.д.) т.е. самого фреймворка. Отголосок этого, есть и у Вас в Yii2, а именно тот самый web.php, что возвращает массив настроек.
Все "настройки", так или иначе - глобальны, ибо действуют "на всё". Но, в варианте ООП, Вы создаете класс конфигуратора (нафига?). Далее, глобал - не моден (и только!), а поскольку оно все равно надо пробрасывать везде - значит создаем "хранилище" в виде Yii->app, Vault и т.д. (нафига?), и наворачиваем целую оркестровку из нескольких сущностей.
Вы что-то получаете взамен? Очень сомнительно, но вот КПД снижается качественно.
Да, существуют разные способы конфигурирования, от возвращения массива PHP, до разного рода Yml, Json, Xml описаний. Стремление угодить всем приводит к росту классов, хелперов, интерфейсов .. ради попытки "расширить аудиторию и снизить порог входа" и только. А стремление впихнуть невпихуемое, приводит к динамике и автоподгрузкам требуемого конфигуратора и в конечном виде выливается в большой объемный bootstrap с поведениями, событиями и пр. "наворотами".
Оплата таже самая - качественное снижение КПД интерпретатора в целом и гигантский рост потребления как времени так и памяти, и в конечном счете те самые 250+ классов (Laravel) выросли отсюда, не смотря на неплохую идею изначально. 2.5 мегабайта на настройку - типовая плата, практически ВЕЗДЕ, при требуемом объеме в реале в .. 0.05Мб.
Этим ещё Zend страдал, что и побудило меня написать эту пародию на него на чистом PHP, где-то в 2013-м и теперь оформилось в USSR
2. Базовая задача - разобрать запрос на составные элементы, защитить Приложение от инжекций чего не положено, оставить только полезное и найти кому передать формирование ответа. В самых модных(а не полезных!!!) фреймворках, каждый чих выделен в свой класс request, route, etc. Стремление сделать "все по науке ООП" привело к появлению под ними разных интерфейсов, абстракций, моделей и т.д. Что вынуждает интерпретатор .. грузить всё от самого низа, до самого верха, ибо оно указано в используемых фичах в use...
Это ли хотел условный "разработчик Приложения"? Боюсь что совсем нет. Ему нужен простой и вменяемый набор данных из запроса, пробрасываемый в его MVC решение.
3. Сборка ответа. И так много, не буду расписывать. Надеюсь в целом понятно и так: всё ровно тоже самое. В реальности требуется собрать в кучку отдельные части ответа и выдать их в заданной последовательности или вывалить грамотно оформленную ошибку. Что имеем? А тоже самое - избыточную гору всего и вся, разобраться в приколах которой стоит больших затрат разработчику.
4. Доступ к БД. Подход Yii2, кмк в целом продвинутей чем "у других", но имеет свои недостатки, связанные .. а все с тем же желанием делать все "по теории ООП". Всё таже избыточность классов, трейтов, ООП решение к формированию запроса и отдельно работающий "построитель", понять работу которого .. а туда вообще мало кто ныряет! О как.
В тоже самое время, типичному сайто-писателю требуется совсем ничего: получить сущность, отдать клиенту и поправить согласно ответу. Или выдрать из БД требуемый массив записей, связать с ними нужный комплект зависимых сущностей и отдать это все, часто списком, или вовсе в табличном виде (галерея товаров к примеру). Но .. модель заточена на "объекты" и начинается .. циклический перебор ключей записей в поштучной фильтрации найденного. Редко? Да сплошь и рядом! Полистайте этот форум: 150 запросов к БД на страничку - НОРМА!
Да, тут Yii2 позволяет вести себя грамотно. Но .. какой ценой?
Аналогично .. получили кучу барахла с запросом. Это всё надо запихать в БД .. какой фреймворк предоставляет "множественную запись одним запросом"? А ведь Скуль только так и заточен ..
DRY, KISS, YAGNI, SOLID .. нарушено ВЕЗДЕ, ибо извращен сам смысл абревиатур.
Вам есть куда двигаться, и как улучшить проект. Надо просто тщательно присмотреться и выкинуть из него всё лишнее.
Кстати, показанная скорость и требуемый объем в USSR, это вместе со встроенным профилировщиком и сбором отладочной статистики, то самое что Вы просили "отключить" для проверок.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР