Static vs Singleton

Singletons not only are not needed in Apex, they are basically pointless. In that previous thread, I described why stateful singletons are pointless, but stateless singletons are pretty much in the same boat, simply because the instantiation/cache step is unnecessary.

In Apex, I've found that abstract utility classes with all-static methods are the equivalent of a Java/Spring service layer (without dependency injection). In practice they behave the same as a stateless singleton class anyway. We have dozens of these in our app, which are used to do anything servicey, such as the describe call caching you mentioned.

When you're in an environment that is born and dies within the scope of a single (single-threaded) request, the singleton pattern is irrelevant. Static achieves the same ends, including state sharing within the request if that's what you need.

In my opinion static is all you really need when working in this environment due to the fact that code runs in a new context each time the user performs an action.

I've used singletons a lot when writing games, typically I'll have a single instance of a class called SoundManager, one called InputManager, and a bunch of others that are responsible for managing particular interfaces and resources. In this context you wouldn't want to have more than one instance to keep memory usage at a minimum, but you may not want to flexibility to destroy objects when they're not needed.

For example, a front-end menu manager would likely not be needed in-game, so it's prudent to delete it and free up the memory it's using. When you're back in the front end you can create a new singleton instance and wouldn't want to have more than instance trying to manage the display.

Singletons have a purpose in APEX. The real power in it lies in avoiding multiple queries in the same trigger context. In a complicated trigger; this is crucial when we consider Salesforce governor limits.