Another advantage to using the Paamayim Nekudotayim (aka. Scope Resolution Operator) is that you can have a class which might do translations, or calculations or rather generic stuff which may not need to be a fully instantiated object, and still wrap all that functionality up into one tight group.
For example, think about a registry (or configuration object). Chances are you're not going to be doing anything to it that you need to constantly call private/protected methods, and you may not always want to have an instance of it everywhere you want to use it. But if you make it have all static functions (or use a few static functions) and the Singleton pattern, you can allow for reading, writing, deleting, and updating of a configuration object (or registry) without the need to make sure that you have an instance of it. At the same time, you can also be assured that when you call on it, you're acting on the same instance, and not just a new default object.
The down side is that you have to use a lot of Singletons if you store anything in your objects which removes many other patterns that you could use during development. You also can't duplicate, clone, or create new instances of the object because it would be all static methods.
There are arguments on both sides as to which is "better" and it really comes down to the situation you're dealing with. A good example of a purely static class would be a registry or configuration object which will be static throughout your application; however, it can be read from anywhere because it's pseudo-global if you have paths set up right and some fancy autoloading features. If you are doing something like creating a feed generator which may have RSS and Atom output, then static methods in a class don't make much sense since assumingly you'd want to have both RSS and Atom extend a "Feed" class and you'd want to be able to have multiple instances of that class to operate on.
