Когда решил создать лошадь⁠⁠

Можно и напрямую, но это добавляет сильную связанность в код. В итоге в нужный момент придется выковыривать инстанцирование конкретных классов по всему коду, чтобы заменить на другой класс или везде в этих местах городить условия, когда в рантайме нужно будет создавать условно объекты другого класса. В итоге код раздувается от таких условий и становится менее читаемым и хуже поддерживаемым.

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

Если же применить DI и передать в метод абстрактную фабрику объектов, то зависимость "обращается" и класс создает через фабрику объекты "какого-то" класса и вызывает его через абстрактный интерфейс, в результате связанность ослабляется.

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

Это вкратце.

В реальности сразу на входе не нужно городить фабрики фабрик, но когда зависимость начинает распространяться и мешает поддержке или тестированию, вот в этот момент надо провести рефакторинг.