What horrible advice. Static classes should almost never be used. First understand the difference between class & object. A class is a definition, like a blue print. An object is what is built
from that blueprint.
Differences in State
When you store some static data (use a static class with static variables), those variables are stored with the class itself. Since the class is the blue print (the class you type into your IDE itself), there can only be one set of state.
However there can be unlimited number of objects per each given class, each time you instantiate the class it creates a brand new object with new state. A static class may seem to make sense when you want "one" (for example "one logged in user") - however when you suddenly need to re-use the same logic for more than one user you've got a lot of backtracking
Coupling
Another difference is in coupling, this difference is slightly harder to understand (maybe). When you refer to a static class you refer to the name of the class, the name of that class then gets repeated into your code which introduces "coupling" (places that must be changed if you want to change that behavior). This breaks a design principle called 'dont repeat yourself' (one place to make a given change, one reason to change something)...
Objects on the other hand, can be passed as arguments, through the constructor of a collaborating object. Therefore collaborating objects don't need to know what kind of objects are being passed in. One day it could be a User object (representing a logged in user) - the next day they could start receiving instead a Registrant object (representing a user that is in the middle of registration process). This is where interfaces come in. If you program by interface and you avoid static classes, your software becomes more cohesive and less coupled.
A big example with coupling is what if you want to take some code and use it in another system - how much work is that going to take? A lot more if your code is static. You can prove this to yourself with unit tests. Static code is incredibly hard to exercise under unit test, which means its hard to take that code and exercise it outside of it's original environment. If code is easy to unit test (dependency injection) that means its easy to "trick" our object into collaborating with new objects, or "trick" it into running inside some new system, almost like a kidney transplant.
Dependency Injection
This just means, when you want to call a method on another class, DONT refer to that class from within a method's definition. Instead of "calling" that class, "ask". This is the holywood principle. Don't call us we'll call you (stupid saying to help you remember). In other words, don't instantiate classes, or call static methods all over the place. Instead accept collaborating objects as constructor arguments. For example maybe you have a Newletter class that operates on a User class. You don't want to couple that Newsletter class to some given User class - but the two classes do need to work together -thats where you use dependency injection
http://martinfowler.com/articles/injection.html