The prevalence of static helper classes in based on a misconception.
Just because we call classes with only static methods "utility classes" does not mean that it is not allowed to write common behavior in POJOs.
static helper classes are anti pattern for three reasons:
The static access to this helper methods hides dependencies. If these "utility classes" were POJOs you could inject them int to a dependent class as constructor parameters which would make the dependency obvious for any user of a dependent class.
The static access to this helper methods cause tight coupling. This means that the code using the helper methods is hard to reuse and (as a side effect) hart to test.
Especially if they maintain state these are merely global variables. And hopefully nobody argues that global variables are any good...
Static helper classes are part of the STUPID code anti pattern.
Global state is unrelated to the question, – max630
The OP wrote:
But mostly it is indeed context dependent and statefull.
Static statefull constructs are global states.
any kind of code can use it. – max630
Yes, of cause. And almost all applications need some kind of global state.
But global state != global variable.
You can create global state with OO techniques via dependency injection But you cannot avoid global state with statefull static structures which are global variables at the bottom.