The particular example he's giving is of recovering a password from a file, where the password is hashed into something like an encryption key using a standard algorithm. If you've stolen the file, you can then recover the passwords using various mechanisms.

There are various levels there, but the speed of brute-force lookup you can do on a file of password hashes exceeds the theoretical network rates -- it's not simply a matter of slowing things down, even a site with no blocking mechanism is going to only be able to do a few tens of thousands of login attempts per second on a single account, and as you say, adding some kind of throttling and lockout is pretty easy.

By contrast, if you've got the file locally, you can try depending on the example, up to nearly a trillion and a half possible passwords per second. The encryption type matters a lot, though -- the best algorithms are about 1,000 times slower to test per http://hashcat.net/oclhashcat/ and there are other techniques that can slow down the test rate by a roughly equal amount.

That's still at least a million tests per second locally, something that's virtually impossible against any kind of individual public network endpoint unless you've got an entire botnet at your disposal (and maybe not then -- and a million failed logins in that time frame are going to register on someone's console even at a site like Facebook or Google.)