Utility classes are code smell (paradigm smell, even). They exist where the OO model breaks down and you want to get-shit-done rather than spend an hour thinking about where you can stick function X so that it's useable by class Y and Z. Same goes for verb classes; you know, those does-the-thing classes that you create which are just objects wrapped around a single function called execute(), run(), create(), etc. etc.
Utility classes serve merely as organization purpose. It has nothing to do with OO. It's like putting related files in a directory, or putting related Python functions in a module.
I don't get how "stick function X so that it's useable by class Y and Z" is relevant for consideration. As the name suggested, utility classes are function libraries that can be used by all.
The problem is that what you "really" want when you're doing this is a plain old namespace. In some languages, objects necessarily come with a bunch of baggage and implications you don't want without some way to opt out.
Yeah it works fine most of the time, but it's a bit like the opposite of primitive obsession. You wouldn't use an Integer class for an index in a for loop.
In Java you have little choice but to dump it all in one place. Contrariwise, Python offers you more options; you can just make a module and put a bunch of top-level methods in there if you want. Go has some notion of "objects" but you can have methods or top-level functions in a given package. And so on.
No, the problem is not to use a namespace. The problem is I want to organize related functions as a group. Namespace is just one way to do it. There are other ways. Package, class, namespace, or module serve the same function in term of organizing functions.
What are the bunch of baggage and implication to use class as a way to organize functions?
I don't see the difference in usage you mentioned with Python module. Putting a bunch of "top-level" methods in a module is the same as putting a bunch of static methods in a class.
