Ci sono motivi per non utilizzare un framework DI su un progetto standalone?

Ecco l'unica iniezione di dipendenza di cui avrai mai bisogno:

public MyConstructorMethod(MyDependencies) { }

Semplice, non è vero?

Allora perché hanno i contenitori DI? Bene, preferiresti dire questo

var svc = new ShippingService(new ProductLocator(), 
   new PricingService(), new InventoryService(), 
   new TrackingRepository(new ConfigProvider()), 
   new Logger(new EmailLogger(new ConfigProvider())));

o questo?

var svc = IoC.Resolve<IShippingService>();

Certo, questa è una semplificazione eccessiva. I contenitori DI gestiscono un certo tipo di complessità, ma aggiungono alcune nuove complessità. Nell'esempio 2, come fai a sapere cosa viene iniettato se hai un problema che devi risolvere? Inoltre, se le tue dipendenze sono complicate come l'esempio 1, probabilmente dovresti affrontare prima tale complessità.

A mio parere, i contenitori DI si dimostrano validi in applicazioni che presentano grafici di oggetti molto grandi e complessi. Questo potrebbe spiegare perché non li vedi in strutture di piccole e medie dimensioni.

Ulteriori letture
Inversion of Control Containers e il pattern In Dependency Injection
Perché ho bisogno di un contenitore IoC invece del codice DI semplice?

Sì, complessità. Un framework DI rende il codice più complesso e la complessità rende il codice più soggetto a errori e più costoso da mantenere. Ma su un sistema sufficientemente complesso, un framework DI semplifica la gestione delle dipendenze e il test dell'unità, che a sua volta lo rende più facile da mantenere. Quindi è sempre una questione di compromessi e determinare a che punto i benefici dell'aggiunta di un framework DI superano i costi. Questo non è sempre facile da determinare.

Non direi che un framework DI può essere pericoloso . Anche nei casi in cui è eccessivo, per lo più sarà solo un trascinamento, ma non affonderà il progetto. Solo se è un sintomo di una tendenza generale a sovraccaricare tutto, diventa un pericolo.