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:

1. 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.

1. 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.

2. 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](https://williamdurand.fr/2013/07/30/from-stupid-to-solid-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.