The sites that have easily scaled bcrypt include many so large that this argument has basically been mooted, but if you want to nerd around with it: you would hypothetically just turn the cost factor down to accommodate load.

It doesn't need to run it for a couple thousand a minute, there aren't that many people registering with NPM at any given time.

Sure, but how many people are using it? You would need to verify the password on each request (since you can't use browser cookies).

The operations npm needs to log in for are a fairly small percentage of the total. If you need to upload a new version of a package, then that takes a password. If you just need to search for a package, or download its latest version, those don't need authentication. The overhead from using proper slow password hashing would be minimal.

And evidently the CouchDB guys agree with me, because they switched to using PBKDF2 for password storage -- essentially, iterate SHA several thousand times to make it slower.