It seems the online community bounces between extremes. I've found that there's a good balance between using singletons and dependency injection. I use DI for anything I will be unit testing -- the idea of 100% coverage is a waste of resources -- like my domain model and services that operate on/near the domain. For my UI level and things like email services, auditing, or unit of work managers (see Ayende's blog) I tend to use static classes because I'll only ever be doing integration level testing and static calls really clean the code up.

I agree with the basic idea, Ryan, of using the right tool for each job.
Keep in mind, though, that static classes and methods live 'forever', so you should check what state they might hold.

The other side of that coin, of course, is that static methods load up at application start, and don't need to be reloaded later, right?

And another point to strengthen your argument is that in real world programming, you don't really always have time for perfect code, and OOP isn't the only way to go.