The ratio of write/read does not seem to be the problem. After a certain amount of write traffic the view indexing and storage problems appear - regardless of the amount of read traffic. More writing means more of 1. and 2. and the more likely the database enters the dreaded more-than-half full phase. I have cron job compact the database every 6 hours. (I'm the blog post author.)
In the next article, titled "What I look for", he mentions that he'd never use a stored proc to access data through SQL.
To me it sounds like he is almost refusing to use an RDBMS to its fullest.
Using map/reduce has taught me where RDBMS systems excel and what I've taken for granted. Its the simple master/master replication feature that is very attractive. RDMBS emphasises perfect consistency when eventual consistency is a better tradeoff for most webapps (IMHO).
1. View index updates - "Every write sets up a trap for the first reader to come along after the write"
2. Append-only database file - "Create(s) a huge operational headache", disk utilization, compaction, etc
CouchDB has always been a poor choice for write-heavy applications. Sounds to me like a case of selecting the wrong tool for the job.
Though I'm a big CouchDB fan myself, I wonder why the author didn't go with a traditional RDBMS for this application.