Even worse, if your under engineered product is causing problems, you'll almost certainly notice it (rather quickly too). If you over engineer, you may never realize it.
Designing for dependency injection is mostly about passing objects around as a parameters instead of using globals / singletons.
It's in big code bases where the tempatation to use a singleton is greatest, because no one wants to refactor all the function signatures to add the extra parameter.
Oddly, I think the problem is often lack of a global namespace. Consider how you pull in the "parseFoo" method. In languages with a global namespace, you just use it. You can put a declaration saying the method has to exist, but no need to import it from anywhere. That is a build time concern, not a write time one.
Even better, changing the implementation does not require changing the user site, at all.
Namespaced languages have to use factories and abstract factories to get the same flexibility. (Or dependency injection.) I don't even think they're bad ideas, just find it interesting how much effort it takes to change which method I'm actually calling.
But even if dependency injection has all the costs you claim for it. Those costs are at their smallest when the system is small. So I still say xypud is wrong: you should do injection by default and when it gets too cumbersome then you think about how to streamline the interfaces.
In practice, I agree with your point. I'd rather do some small costs up front. I'm curious to explore the designs more. I think in systems where you have independent programs working together, a lot of this solves itself. The trend today is to make things one big program. (Not a new trend.)
Only nowadays all usually includes significant 3rd party library code and everybody is stuck trying to figure out how to get their DI magic in place when said 3rd party code doesn't cooperate.