I always deplore this shallow influencing of design patterns without proper examination of whether said design pattern fits or is even correctly described by the popularizer. People fail to realize that inversion of control is necessary ONLY if some controls need to be inverted.
To be fair, "inversion of control" is a great concept, but unfortunately told in a very specific way across time so the meaning now has changed into an inferior form of the original.
I do personally think it's preferable for components to have their dependencies injected in some way, and that it's better to have initialisation logic (especially related to heavy weight components) in one place.
That doesn't mean that you need some huge ass meta-framework for it though. Just have your main function assemble the components together, done.
Even this is an over simplification of inversion of control.
Dependency injection is one form, but even a library that exposes parameters is also a form of inversion of control.
The degree of control is what varies, whether it is a mere flag (boolean), a variant directive (complex struct), a turing complete construct (pointer of instantiated function) or anything in between.
What I am saying is that this concept has been reduced as it is popularized and it isn't doing justice to the original powerful concept.
To be fair, "inversion of control" is a great concept, but unfortunately told in a very specific way across time so the meaning now has changed into an inferior form of the original.