Now, what I'd say to that kind of argument is that a good static method, which could really live on its own as a function out there in the world, is something simple enough you'd never want to mock, or is something that is so specific that you'd always want to inject. This is easier to understand if you are used to functional programming styles, and therefore also realize that automated dependency injection was a misstep. It's also easier to get if, like in Scala, there is no such thing as a static method, just classes that have only static methods, and classes that have none.
But until one has 'seen the light' of FP, static methods that are complicated and are not injected will be annoying when someone is trying to not call them in a unit test. Therefore, in some places, static methods are always avoided.
In fact, dependence on mocking frameworks is a huge code smell because it covers over the common practice of not coding to an interface. If you want to expose poor design in a code base, remove the mocking decencies and see how hard it is to rewrite the tests.
I think some people put unit testing to the extreme by not wanting to test logic outside of the unit tested (which is not possible to do fully). They write additional code for mocks so their tests could be less useful but more "pure".
