At the time we choose sha1 because the password hashing for creating new user documents was done by the client, often in the browser. At the time there were no good bcrypt implementations in JavaScript. Here is the related bug tracker issue https://issues.apache.org/jira/browse/COUCHDB-1060
That's part of bcrypt's reason for existing. In order to protect against brute-forcing stolen hashes, bcrypt has to be slow enough to make brute force impractical. This isn't a bug; it's a necessary feature. If the server they're running npm on is so old or so overloaded that the slowdown from using bcrypt would even be particularly noticeable, then they have other problems.
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.
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.