I don't use them a lot. Sometimes they seem to make sense, but I always worry about the cohesion of my classes...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I use helper classes and util packages, but I don't put them all in one util package. I do try to put logic where it belongs. But if multiple classes use the same logic, a helper class often makes sense. Or maybe I should say a helper object. Many of the helper classes don't have static methods.
For example: mycompany.util - Generic things like StringUtil, DateUtil [this is the kitchen sink, everything goes in it package] mycompany.component1.util - Helper classes having to do with a certain component
Whether or not helper classes are a good idea depends largerly on whether they follow the object-oriented design principles and whether or not they introduce any code smells. The single responsibility principle sometimes drives the creation of helper classes as inclusion of their functionality could leave the core class with multiple responsibilties. Helper classes may also be created to stick with the DRY Principle (Do not Repeat Yourself); i.e. a piece of code that somehow seems to appear in all sorts of places needs to be consolidated in one place but doesn't have a natural home (though one should use this case very sparingly - it's more likely that you don't yet fully comprehend what's going on in your object model).