With DI you can ensure you're not accessing anything that's globally defined. While you can mock out global objects and methods on global objects, it becomes far less clear what the ramifications of doing so becomes when your app becomes large and complicated. With DI, you have all the dependencies clearly defined for the function you're concerned about.
Beyond testing, DI makes it much easier to swap in different implementations of a dependency than simply throwing things into the global scope lets you do. Suppose I want to switch my model from one that communicates with Parse to one that communicates with Firebase. Supposing I adhere to the same interface, I should be able to simply drop it in place without affecting other functions or objects that still rely on the Parse version of the model.
Your first point cannot be debated, since we are speculating. In practice, I'vent seen a problem. It works, it's clean, and it is the right amount of engineering needed to solve the problem.
Parse and Firebase example:
//someservice.js
...
//works as long as both retain the same interface.
provider = new FirebaseProvider; //new ParseProvider()
//add: just using an if condition, the old fashioned way.
getProvider: function() {
if (config.provider === 'parse')
return ParseProvider()
else
return FirebaseProvider()
Why is writing configuration cleaner than doing the above? That thought process is carried over from projects with lengthy build time.
Whether or not Angular's implementation of its provider is cleaner is irrelevant to your original point that DI is a "problem looking for a solution" in dynamic languages.
Dependency Injection is a redundant, useless pattern in dynamic languages; especially when it comes to testability.
In test.js:
The above over-simplified example satisfies most test cases. You can convince me with some use-cases.(Edit: You weren't misrepresenting what I said. Removed that claim. I misread, apology.)