Well I've read all the other answers and I notice that they all miss an important point.

The static class members are created (and destroyed) outside of your control and if that creation is expensive and you never use it then that's not too efficient.

An explicitly coded Singleton (using a Factory as a rule) would allow you to create the Singleton instance as and when needed (ie the first time the factory is called), and destroy it if you decide that's more efficient.

With pattern, you main purpose is to reuse an existing design, and most importantly, effectively communicate your ideas with other developers and architects.

You can probably do just about everything using static class as you can with Singleton. If someone is looking over your design, they might be questioning why you want to put a static class in a particular location. If you using singleton, on the other hands, it sends a clear sign that you want a single entry class.

With a Singleton pattern you can separate the actual Singleton class and the class that provides the Singleton.
This makes the implementation of the Singleton class replaceable (even at runtime), e.g.

public class MySingletonProvider {
  private static MySingleton singletonInstance = null;

  public static MySingleton getInstance() {
    if(singletonInstance == null) {
      singletonInstance = new MyConcreteSingleton1();
      // or new MyConcreteSingleton2()
    }
  }
}

public interface MySingleton 
{
  void method();
}

public class MyConcreteSingleton1 implements MySingleton 
{
  public void method() {
    // do something
  }
}

public class MyConcreteSingleton2 implements MySingleton 
{
  public void method() {
    // do something else
  }
}

As you can see, the provider class could choose different implementations of a singleton (e.g. based on informations in a configuration file). You could use this to provide several logging mechanisms, one for logging to a database, another for logging to a file, etc.