This statement seems slightly ironic given the prevalence of IoC containers in the most commonly used backend languages and rampant 'interface everything' syndrome alongside it. You'd almost think such a world would embrace AOP.
The most commonly used languages are there because the most conservative people (that hire a large majority of people) pick them.
In the most basic form - passing dependencies to a function/object constructor, instead of instantiating them within said function/object constructor - I feel it's mostly a good idea, but there's something that's bugging me about this, and I'm not yet able to pinpoint what that is.
The more advanced form - autowiring things with magic annotations - yeah, I hated that when I was working in Java. However, these days I think the problem isn't with the idea, but - again - with our insistence on working with the final, pre-binary, single source of truth plaintext code. That is, autowiring is the kind of stuff that really needs support from tooling able to tell you what exactly happens in a particular scenario - it feels icky, but it does so because we're not used to relying on tooling over raw plaintext. And what I'm saying is, we should ditch the plaintext and embrace the tooling, or else we'll remain forever stuck in endless debates about code style, readability, etc. - problems that, to me, seem to be fundamentally caused by hard limits on how many cross-cutting concerns you can cram into a single block of text.
Well, I have seen some heat specifically against the habit popular on Java and C# of passing dependencies into factories and getting classes with completely different interfaces as a result.
But you are correct, IoC is a very generic name that can cover even passing lambdas to a map function.
Anyway, the problem with deviating from the single source of truth plaintext is that when other sources of truth have bugs, you are usually forever unable to fix them¹. This is because when people create tools that affect the program behavior independently of your source, they inevitably make them stateful. A stateless tool could in theory not have this problem, but then, developers are annoyingly good into reducing your stateless tool "configuration script" into normal code and using that instead.
1 - There are many programing environments where tools affect the program behavior. Those are usually aimed into novices and non-programmers, because programmers with any experience are quick to reject them. A very common theme on those environments is that error that keeps happening despite everything being correct, and can only be solved by throwing your work away and doing everything again exactly the same way from scratch.
In other words, you saw a bug in a software implementation.
What leads you to look at a bug and from that lay broad and overreaching personal claims about fundamental design patterns?
I have no idea where you got that from. Inversion of control is perhaps the most important design pattern ever devised, and IoC frameworks make or break any project.
Where exactly did you get your personal assertion from?