Разница в том, что первично. В его схеме первична инфраструктура. В неё нужно отправить объекты приложения, дальше она сама разбирается с ними. Для этого и придумали инверсию управления (IoC). Иначе будут траблы, так приложение начнет управлять фреймворком, что нонсенс.

Но этого мало, еще желательно применить DI, так как инфраструктура претендует на универсальность. Она должна уметь работать с любыми классами приложения. Это же фреймворк по сути. Вещь главная и самодостаточная. Фреймворк должен поместить в свою среду пользовательские объекты и обработать их. А это удобнее всего сделать через внедрение зависимостей.

А там, где используется DI, нужно свято следовать принципам DIP, который входит в SOLID. Нужно понимать, что цепочка раскручивается наоборот. Именно SOLID придумали для упорядочивания таких схем, а не все схемы строятся исключительно по этим принципам. Программа может быть построена и по другим канонам, просто это перестанет быть фреймворком.

Разумеется для более грамотного упорядочивания таких схем удобно использовать DIC. А вместе с ним уже накручиваются карты, обсерверы, локаторы, медиаторы и пошло-поехало. В итоге для того, чтобы запустить пару классов приложения, нужно заюзать пару десятков классов инфраструктуры. Это принцип Push (толкать). Инфраструктура "толкает" приложение.

Если строить программу по принципу Pull (тянуть), то первичны классы приложения. Его нужно только запустить, оно само вытянет из окружения то, что необходимо для текущей задачи. И тут IoC теряет всякий смысл. Приложение не может не зависеть от библиотек, как и библиотеки не могут зависеть от приложения. Соответственно пропадает надобность в DI на глобальном уровне. А вместе с ним и всей веревки классов, обеспечивающих интеграцию.

И поэтому количество задействованных в формировании страницы скриптов падает на порядок - раз. Появляется возможность использовать различные методологии, не только ООП - два. Хотя внутри модулей и компонентов можно спокойно юзать всё, что душе угодно. И абстракции, и DI, и свято придерживаться SOLID и паттернов наворотить гору. Никому это не вредит, так как библиотека не зависит от приложения и штука весьма автономная. Эдакий микрофреймворк.

У такй схемы есть конечно недостатки.

Первый, на мой взгляд не самый важный - сложность тестирования. Но для этого есть свои приемы, не обязательно юзать юниты.

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

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

И вот это и есть основной камень преткновения. Для того, чтобы разрабатывать ПО быстро и без особых усилий, вполне годится схема фреймворка. Однако за это приходится платить оптимальностью и прозрачностью. Про оптимальность думаю и так понятно. А вот с прозрачностью спорный вопрос. Если фреймворк популярен и хорошо документирован, то еще куда ни шло. А вот попробуй разобраться в поделке от chee.

Так вот, а если это конечный долгоиграющий проект, который тебе же и приходится обслуживать, то на мой взгляд лучше

Так как инфраструктура минимальна и выверена годами. А функционал приложения и библиотеки гораздо проще модифицируются, так как система дискретна, а не связана в один узел. С которым и призваны бороться "новейшие технологии". Такие как IoС, DI, DIP и куча паттернов.

- - - - - - - - - - - - - - - -
Для тех, кто не в теме.
IoC - Inversion of Control (инверсия управления). Принцип взаимодействия приложения с окружением.

DI - Dependency Injection (внедрение зависимостей). Передача объекта в область видимости базового класса.

DIC - Dependency Injection Contayner (контейнер для внедрения зависимостей) Эдакая централизация зависимостей. Функционал, регистрирующий и хранящий объекты. Служит для передачи зависимостей скопом.

DIP – Dependency Inversion Principle (принцип инверсии зависимостей). Зависимости класса должны располагаться на текущем или более высоком уровне абстракции

SOLID Сами читайте

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

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

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