They are hard to test only if they are not functions and access some global mutable state. In vast majority of cases static methods are functions and are easier to test than normal methods, because you do not need to initialize object.
I suspect that the issue that the GP is discussing is not that they are hard to unit test, but that they are hard to mock: If you don't want to call the static method, either some relatively unfortunate thing has to be done to your mocking classes, or you have to inject it, which is uncommon in this kind of situation in your typical Spring application.
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.
But Java has a solution for the “good static methods” you’ve described in the Function interface. I’d submit that a FooLib class with these static methods could be replaced with a foo.lib package with the corresponding Function implementations. This allows great flexibility with unit testing because you don’t even need a mocking framework. Instead, you just provide a dummy implementation of the Function the unit under test depends on.
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.
If static method behaves like a function I see very little reason for mocking. Do people mock also calls to complex constructors (which are too static methods)?
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".
