This programming practice is bad in purely object oriented languages (like Java) because it undermines the object oriented programming paradigm. They work, but once you realize you DO need more than one version of them, you will need a lot of refactoring to achieve that.
If you think that handing too many parameters via method calls is cumbersome. Simply create an object that holds all of them (see Peter Lawrey's answer, "Context" object) and pass only this object. Then you can again use your "simple dot notation" on that object.
Next point: Testing. If you need to replace some static fields with proxy or other testing stuff for unit tests, you are basically screwed. With a context object, you can simply hand a different context object into the unit tests.
The Utility class you mentioned is basically a good candidate for such context object. Simply make all its fields non-static and hand in an object of that class to code that needs it.
I can tell you about one example where I got screwed by using statics: I once wrote a compiler. And since I thought that during a compilation run, there are many context things that are only necessary once (the symbol table, for example), I added them all as static variables. Later I decided to allow multi-threaded compilation and a "server" mode where the compiler runs all the time in idle mode until a client sends a compile request (this saves Java's long startup time). Now I was screwed. Now there was more than one concurrent context (concurrent compiler threads), but all context was shared via static variables. I needed around one week to replace all statics by context objects and introduced numerous bugs.
