The first thing I did on that page was add "membase" to the list. If one adds the "couchdb" and "membase" lines, the result almost - no, not quite - keeps up with the MongoDB line. This is compatible with my first thought that people have had trouble keeping up with Couch's continual changes in name and direction. Relatedly, Couch* (the company) has often failed to provide a comprehensive solution, requiring users to grab other pieces from other places - e.g. BigCouch from Cloudant or Futon from the Apache project. Contrast with 10gen/MongoDB: consistent name, consistent direction, single source for the whole solution including client drivers.
There are other factors as well. I've heard some people say that Couch* is a serious memory hog. Others have complained about dependencies. The REST interface appeals to some, but others would prefer a more binary-oriented protocol. The relentless positioning vs. MongoDB, and particularly some of the FUD being slung by Couch* advocates (hi rdtsc) is generating a bit of a backlash as well. For all I know some of these issues no longer exist, perhaps some never existed, but without a focused effort to deal with these impressions they remain liabilities. Couch* comes across not only as developer-oriented, but oriented toward a particular kind of developer.
Note that none of these factors relate to the technical quality of the two products. I think Couch's general distribution/replication model is fundamentally a better one than Mongo's, though I think Mongo wins by having real ad-hoc queries instead of requiring the moral equivalent of stored procedures. I thought little of Mongo's answers regarding durability and replication (and TBH still don't think they're at the level they should be) but I could see that progress was being made and I have enough of a long-term perspective not to get all perma-caremad about it. In the end, I think Couch* has been held back a bit not by its technology but by all the "other stuff" that goes into making a project or company successful.