Inversion of Control as Loss thereof

Wikipedia, defines Inversion of Control as "an abstract principle...in which the flow of
control of a system is inverted...". In other words Interface molds,
churning out pieces that snap together like Legos, create small rungs
as the foundation for the next code layer. Just like a salesperson, saying
"do not call us, we will call you", we set up just the functional
interfaces documenting future code.

However, In chapter one of Structure and Interpretation of Computer Programs,
Hal Abelson and Gerald Sussman say that "The ability to visualize the
consequences of the actions under consideration is crucial to becoming
an expert programmer, just as it is in any synthetic, creative
activity". Oppositely, Inverting control of our program requires, nay
demands us to close our eyes to the consequences of our
actions. By programming interfaces rather than functional code, our
ideas lose shape, independence, flexibility, and functionality.

In other words, dependent and ill-functioning interfaces foster
brittle code and opaque models, not necessarily opaque code.

I do not argue with communities suggesting that code abiding to the
inversion control pattern is more robust and less error
prone. But robust, error-free, ill-functioning code is still bad
code. By muddling our intellectual model, we
lose understanding of how our code functions, and thus lose
control. Therefore, inverting program control is nothing more than
loss of control.