I get the impression that the problem was less about scaling within one database than about scaling across many; Lenton practically says as much about a half dozen messages down-thread. Deploying literally millions of separate databases would be a total nightmare of resource contention, version skew, and general administrative burden. U1 was probably looking for ways to use some sort of multi-tenancy to serve the same number of users with fewer CouchDB instances, and that's the kind of scalability they apparently found lacking. Your point about scale vs. federation, while perhaps accurate and valuable, doesn't seem to address the actual reason for this change.
That is exactly how I understood the problem. The term "doesn't scale" is far to fuzzy to describe the problem.
I also see no mechanism in CouchDB to solve this. If such a problem exists, I expect a company to react with architectural improvements. If that doesn't happen, the software does not fit the use case and has to be exchanged. This is really bad for the manufacturer for his reputation as well for the user who loses massive amounts of his investment.