Utility classes are evil?
Utility classes aren't exactly evil, but they can violate the principles that compose a good object-oriented design. In a good object-oriented design, most classes should represent a single thing and all of its attributes and operations. If you are operating on a thing, that method should probably be a member of that thing.
However, there are times when you can use utility classes to group a number of methods together — an example being the java.util.Collections class which provides a number of utilities that can be used on any Java Collection. These aren't specific to one particular type of Collection, but instead implement algorithms that can be used on any Collection.
Really, what you need to do is think about your design and determine where it makes the most sense to put the methods. Usually, it's as operations inside of a class. However, sometimes, it is indeed as a utility class. When you do use a utility class, however, don't just throw random methods into it, instead, organize the methods by purpose and functionality.
I think that the general consensus is that utility classes are not evil per se. You just need to use them judiciously:
Design the static utility methods to be general and reusable. Make sure that they are stateless; i.e. no static variables.
If you have lots of utility methods, partition them into classes in a way that will make it easy for developers to find them.
Don't use utility classes where static or instance methods in a domain class would be a better solution. For example, consider if methods in an abstract base class or an instantiable helper class would be a better solution.
For Java 8 onwards, "default methods" in an interface may be a better option than utility classes. (See Interface with default methods vs Abstract class in Java 8 for example.)
The other way to look at this Question is to observe that in the quoted Question, "If utility classes are "evil"" is a strawman argument. Its like me asking:
"If pigs can fly, should I carry an umbrella?".
In the above question I am not actually saying that pigs can fly ... or that I agree with the proposition that they could fly.
Typical "xyz is evil" statements are rhetorical devices that are intended to make you think by posing an extreme viewpoint. They are rarely (if ever) intended as statements of literal fact.
Utility classes are problematic because they fail to group responsibilities with the data that supports them.
They are however extremely useful and I build them all the time as either permanent structures or as stepping stones during a more thorough refactor.
From a Clean Code perspective utility classes violate the Single Responsibility and the Open-Closed Principle. They have lots of reasons to change and are by design not extensible. They really should only exist during refactoring as intermediate cruft.