• They cannot be tested without instantiating their respective classes (imposing both memory and performance costs).
• They lend themselves to reuse via inheritance and not via composition, though the latter is generally accepted as the preferable approach.
• When passed as delegates in C#, they create a potential memory leak by preventing the garbage collector from scooping up their owner when no longer needed.

So let's put the instance demon firmly in his place. Make every method you write static unless you can explicitly explain it needs to be a member. The only two such explanations I could think of were "it's a modifier" and "it requires private fields". Barring those two scenarios, a function can do just fine being static. For example if we have an Account class, and we want to generate some text summary of the account, it's tempting to add an instance member to Account:

public class Account{
   public String getSummary(){
       return this.getName() + " has a balance of $" + this.getBalance();
   }
   ...
}

I would argue that this is better off as a static method:

public class AccountUtilities{
   public static String generateAccountSummary(string name, double balance){
       return name + " has a balance of $" balance;
   }
}

Now, you get the freedom of using that report logic with any data, not just the Account class or its subclasses. You also get the ability to test it without mocking Account. Yay!

I don't think I've written anything earth-shattering here, but without a concious effort, I find the natural propensity for writing members working its way into my code. We need to combat, or at least to recognize and question our instance instinct (try saying that five times fast). Our code will be that much better for it.