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

А если, например, так? Если максимально "близко к телу". Представим, что определение всей конфигурации IoC-контейнера происходит в одном файле, кодом (не через xml, аннотации и прочую муть, просто в каком-то классе с конфигурацией модулей).
— определение реализации для интерфейсов или просто регистрация классов (самих по себе) в контейнере.
— конфигурирование времени жизни объектов классов/реализаций классов (правил инстанциации — синглтон, сессионный, по одному на каждую зависимость и т.д.), зарегистрированных в контейнере.
— автоматическое удовлетворение зависимостей между всеми классами, в соответствии с определенными выше правилами по времени жизни/созданию при автоматическом конструировании объекта из контейнера.

Таким образом:
— вся конфигурация наглядна и все правила описаны кодом в одном файле. Это, конечно, может не так явно, как "Class class = new Class", но ведь у этого "явного" подхода тоже есть минусы (отсутствие "единого языка", т.е. api который даёт готовый ioc-контейнер). Подход с конфигурированием IoC-контейнера в одном файле может быть непонятен скорее из-за того, что он не так традиционен, конечно.
— по мере роста приложения все новые компоненты (т.е. классы) продолжают регистрироваться и описываться в одном месте, в этом классе-конфиге, наглядно (к этому принуждает в т.ч. архитектура приложения, работающая с контейнером для создания объектов).
— при создании компонента (класса) с зависимостями, зарегистрированными в ioc-контейнере, все эти зависимости отслеживаются и создаются автоматически согласно конфигурации ioc-контейнером (кажется, начинаю повторяться )
— конфигурацию можно иметь отдельную (или на основе первой) для тестов, подсовывая при регистрации для интерфейсов другие реализации, ну и прочее в таком роде.

Понятно, что не все классы обязаны инстациироваться таким образом через сконфигурированный контейнер, конечно.

Т.е. мы (ценой добавления библиотеки, да) получаем в основном инструмент для а) более удобного (чем описание этого всего "своим языком" явно) конфигурирования интерфейсов/реализаций; б) следующего из предыдущего автоматического создания объектов по этим правилам ioc-контейнером, с соблюдением зависимостей между ними.

Это ведь вроде, так или иначе, придётся делать самому. Можно делегировать ioc-контейнеру. Интересно ваше мнение.