My pragmatic issue with using class side methods for Singletons is that it is a bunch of work to refactor the class side behavior to instance side later. Look at the original PWS server for a squeak specific example.
Maybe it used to be, but it's a simple refactoring at the moment, refactor method >> move to instance side. Secondly, I'll worry about later... later, i.e. YAGNI, classes are nice singletons and it seems like useless work to manually implement a singleton when singleton is a built in feature.
I'll have to try it with a real example (like make PWS support multiple apps) before I change my practice.
My design issue is that classes are for making instances (technically for defining behavior of instances). Making them the building block of the program means that I'm giving them extra responsibility. I like to keep the responsibility list as small as possible.
Classes are objects too, just because most classes build instances doesn't mean they all have to. You might not want a class doing both, but I see no reason it can't do one *or* the other. Serving as a singleton works well when it's needed and keeps code simple. Saying a class should only create instances seems a rather arbitrary restriction to place upon your designs.
Singleton-ness is quite easy to code (and with class-instance variables can often be coded once and inherited). So it isn't worth it to me to mix-in my new object along with the class creation stuff from Behavior. My favorite superclass is Object (or my own, domain-specific superclass).
Do one thing and do it well is a great way to tease apart and find new objects. When the real world gives me a new problem, time for a new object. Object-oriented programming, after all.
You can do stateless, functional programming in Smalltalk. Some of the most beautiful parts of Smalltalk use a functional approach.
But loading a bunch of class side utility methods on some stateless Class doesn't feel like good object-oriented design.