So do you claim that singleton patterns are bad habit? I've seen them used many times while viewing engines' source codes.
Other's have already addressed it, and I don't want this thread to descend into yet another long discussion of Singleton's pitfalls like so many others have. But since you asked me, I'll defend my position briefly.
The single worst thing that the Singleton pattern does, IMO, is that it allows you to feel good about outright ignoring important and often multitudinous dependencies that really ought to be thought about carefully, or at the very least ought to be obvious. The globalness and alwaysness of Singleton allows this to happen, and its facade of OOP-ness fools you into thinking that this state of affairs is A-Okay. Furthermore, the singleness of Singleton allows you to make the dangerous assumption that there will only ever be one, and so your typical singleton object never stops to consider how it would have to be in order for more than one of them to cohabitate the same program; worse, many people who do not understand this actually favor this trait as a way to allow them to "simplify" their task -- and as a result, they implement singletons when they "only want one" right now, and come to regret it later when they find out they actually need two or more -- Singleton as an up-front design pattern should only be considered (end even then, not always accepted) when two instances *cannot* coexist, ever, by reasons or requirements that are beyond your control. And the kicker is that a simple global can be cajoled into providing all the essential properties of a singleton design for essentially zero implementation cost -- With the kind of Singleton people write to feel like good OOP citizens, you actually have to write a bunch of code to participate in all their pitfalls and downsides. Sheesh!