He doesn't suggest that the password hash is per-user private data. I don't think he caught onto this issue until later.
Besides the misinformation, I disagree about CouchDB's involvement in this mistake. There's no common use case in which using the _users database for human-created passwords wouldn't be a bad idea. For machine-created passwords that are long, it might be OK.
It's just like the Rails issue from a few days back: insecure by design. Only with Rails there was an obvious workaround, which was used by many Rails shops (I was quite surprised to find that it wasn't as many as I thought). With CouchDB you basically have to skip out on one of CouchDB's major features.
CouchDB introduced new functionality that allows extra use cases, in particular it can now handle npms use case in a secure manner, just because it didnt handle npms use case before and npm decided to expose that information does not mean it was ever couch's problem.
npm effed up is all.