So, we have a server class and a client class. We now have knowledge about our concept distributed over two separate classes, rather than one. This doubles our maintenance overhead. It also increases the separation between our domain model and our implementation model. Yay! Re-engineering just got harder: now your program explicitly has to reference it's own internal structure, rather than the knowledge of the domain. On it's own this is not a problem. In fact, it can make the program more maintainable in some (even many) cases, but it must be controlled. There is a danger that the client will be seen as "the real thing", and the server as just an item of convenience: suddenly logic starts popping up in the client code! Clients become more independant! Suddenly, the old oligarchic order falls as the plebian clients implement a republic!

As far as a time when a singleton is necessary, try having a program where you need an instance of an abstract class Person: you need every person to have their own behaviour, so they need their own class. If any two instances of person have the same class, then you have something seriously wrong with your program: a matter-transporter has probably malfunctioned. Of course, you needn't use a class when there is only one of a kind, as you won't need to allocate versions dynamically. But then you don't get polymorphic behaviour. While in this scenario you could use a variant of the visitor pattern to do the kind of things you might do with mixins, you lose the ability to very strongly enforce your uniqueness constraints.

If you don't want polymorphism, don't use an OO implementation. Polymorphism is what give OO it's encapsulation, because method calls are referentially transparent. The use of classes as namespaces is something that is pretty much idiosyncratic to C++ derived languages. Certainly Objective C and Common Lisp don't do it. Namespace division is done by a separate mechanism. The use of private members is not the same as information hiding, and inheritance and polymorphism are not the same thing.

You CAN implement singleton classes nicely: every public method delegates to a private method which is invoked on the single "real" member of the class. Java example follows:

class Foo
{
    private static Foo theInstance;

    public Foo()
    {
         if(theInstance==null)
         {
             theInstance = this;
         }
    }

     public void frob(int i)
     {
        theInstance.priv_frob(i);
     }

     private void priv_frob(int i)
     {
         //do whatever
     }

}