Also, most of the limits of singletons tend to disappear when you use a framework like Spring. Essentially, all beans created by Spring are singletons as per the default behaviour.
However (going through
http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx) :
1) Spring takes care of the glue. If you want to know what singletons a class uses, you just have to look at the XML wiring or the setters of that class. Also, you don't have to deal directly with global variables - they're being pushed onto you by Spring.
2) Using Spring, a class does not need to know it is a singleton. All it has to do is make sure it is stateless and thread-safe.
3) You don't have to be tightly coupled if you use interfaces. Your singleton implements an interface. And all its clients talk to that interface. Then, it's very easy to plug different implementations through bean wiring.
4) That's indeed a limitation, but that's also the main feature of singletons - it's actually why they exist at all. It's a very important feature when setup is heavy. For instance, I have beans which (indirectly) query a database, read and parse half a dozen XML files and makes a few Internet connections as part of their setup. Doing that every single time I need a bean like this would be crazy. Likewise, it would be close to impossible to implement application-wide caching of anything without some form of singleton.
Actually, I think that singletons + IoC pattern can be the real backbone of an application. With it, designing service or DAO patterns is very easy. You can very easily plug in real implementations, mock implementations or alternative implementations.