I second Collin here.  NOLOCK is fine for some things (as Andy points out).  However, it can be dangerous too and one MUST understand the tradeoffs involved before you use it.  This article didn't even hint at the tradeoffs.

I would suggest that if you really need non-interference between "readers" and "writers" you should use the Read Committed Snapshot Isolation Level available in 2005.  It at least doesn't allow unexpected duplicates and dirty reads.

If eliminating overhead is the prime motivation, you shouldn't be using a Relational DBMS.  File based storage mechanisims are far more "efficient" for churning through large data sets.  There is a lot of overhead imposed by things like transactional and logical consistency, but for most applications the costs of ignoring these things is far greater.  The problem is that those costs are often not immediately apparent.  You certainly can't write a simple article that purports to show a percentage "improvement" -or loss - of logical correctness...

Using NOLOCK indiscriminately WILL bite you, your employer, and your customers eventually and it will bite harder than you might think.