Вся ваша беда в том, что почему то best-practics считается, что это "что-то еще" должно быть "между". А почему не "рядом"?

Я согласен, PHP далеко не идеален, да и вообще нет идеальных языков. Всегда чего-то нехватает или что-то приходится исправлять. Но для этого есть библиотеки. А вот это:

100%-е атрибуты фреймворка. Как раз того, что "между". В чем отличие фреймворка от библиотеки, я писал здесь.

Теперь по порядку Зачем в приложении роутер? Допустим нет такой задачи, сделать ЧПУ (я на работе никогда их не использую, не нужны там они и даже вредят). Так для чего он мне? Рассуждения, что "может потом понадобится" не канают. Не понадобится никогда, его чисто технически нет возможности использовать. Да и вообще, роутер - чистая прерогатива фреймворка. Решение универсальное. Не нужно оно в приложении, где и так все ясно со ссылками. Это нужно только в фреймворке.

Соответственно мне не нужен request. По тем же причинам. У того, что потребуется response, всего один шанс на миллион. И если я начну его изобретать, тут же нарушу принцип YAGNI.

Что касается errorHandler, то он легко реализуется библиотекой. Причем вполне универсальной, которую можно подключить к любому приложению простым include, даже к такому:

<?php

echo "Привет, Мир!";

У меня есть такая. Есть даже лайт-версия чисто на процедурах в одном файле. А вот затолкать её в фреймворк просто так не вышло, хотя я честно старался сделать либу компонентом. Пришлось мудрить с зависимостями. И взять её оттуда теперь тоже проблема, ибо она интегрирована и потянет за собой всякую ересь.

Что еще? Большая часть того, что вы используете повседневно, на самом деле в приложении не нужно. А то, что реально нужно, решается бибиотеками. Которые, кстати, совершенно не обязательно реализуются классами. Не говоря уже об ООП.

Так что легко отвечу на вопросы:

1. Потому что symfony, это фреймворк. Причем мейнстримный. А сборка библиотек на то и сборка, что собирается из разных либ. Которые ну вообще нет смысла держать постоянно под одной крышей. Отдельно они существуют.
2. Компоненты взять можно, но даже в этой статье есть про банан и гориллу. Возьмешь один класс, он попросит второй, тот попросит третий и получишь джунгли впридачу. Кроме того, когда пишешь сам, то делаешь это наиболее оптимально под текущую задачу. Фреймворки и их компоненты обычно избыточны. Ну и главное - да потому что ты программист в конце концов. А не сборщик на конвеере.

Что касается спагетти. Код inpost'а можно критиковать по разным поводам. Но уж точно это не спагетти. Это локальное решение конкретной задачи. И ничего сложного и запутанного тут нет. Это классический KISS. Потребуется еще 10 пообных задач, будет рефакторинг. А если не потребуется?

Вот спагетти. Причем с претензией на ООП. Так что оставь этот модный термин, он не применим к парадигмам.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.