func addOp(a, b, op){ return op(a) + op(b); }

Here op is a function being injected into another function. Nobody uses the term in functional/procedural programming because this pattern is obvious and ubiquitous in Higher order functions like map, reduce or filter.

When people use DI though it's used in the context of OOP, where a dependency is an object getting injected into another object through a constructor. People using this pattern tend to create programs that are littered with very abstract objects that can only work when injected with dependencies. Also the injected objects themselves may be DI dependent as well leading to crazy dependency chains (reminds me of inheritance ugh). All of this is done in the name of "modularity" and "unit testing." As you can imagine this pattern produces a sort of False composability where your code is littered with very abstract objects that are rarely ever reusable. If you want to compose object A and object B, you have to specifically design/code object A so that it can handle object B or vice versa. Because all object composition involves custom modifications to the code of an object it is a sort of broken implementation of modularity and reusability.

In a function, the only requirement for composability is matching types. All functions that return ints can be composed with one another without additional modifications. This is true composability and true modularity. The above example doesn't need dependency injection the same result can be achieved with this:

func add(a, b){ return a + b; }

add(op(a),op(b));

So you can see why the OP listed DI as one of his complaints. He must be dealing with a highly Object Oriented code base that employs this pattern extensively.