Idk. Depends entirely on what kind of code you're writing. Singletons are extremely useful patterns for video games, for example. There should never be multiple instances of classes that handle things like game state, achievement unlocking, display/resolution managing, etc.

If they didn't enforce their own singletonness then you'd have to always launch the game using the exact same startup routines, to ensure that only one of each ever gets instantiated. But game engines typically divide the game into something like "scenes", which logically divide code and assets to only what's relevant for that area of the game. When testing a specific level/area/scene, It's extremely handy to have a singleton class exist in every scene, that acts as that startup routine, so you can start the game from any scene, and when you load in another scene through gameplay, the singleton class itself makes sure no duplicates exist, instead of having some kind of manager that keeps track of all that (which itself would also have to be a singleton, so you'd just be kicking the can down the road).