This article is very old (in internet years) and Mongo moves very fast. So most of the things in the article are way, way out of date. Very smart people working at Mongo understand where they need to get and how to get there, and they are well along the path. Bad old code is being replaced with better new code, limited mainly by backward compatibility bother.
It is still the case (and will remain for a long time -- also internet years) that to get reliable behavior, you need to use non-default options. Queries need a variety of extra flags that say, "please make this write durable", or "please be sure to give me the right answer". And, when you use the flags, they reliably make the DB slower. If you use enough of them to get ACIDy distributed reliability, it's hardly faster than other DBs.
So, in another two or three years, it will be an OK choice. In the meantime, PostgreSQL is arguably the better choice. And, of course, PG is not sitting still, so may still be a better choice in two or three years.
But most people using MongoDB don't care, because the overwhelming majority of uses of data storage just don't matter very much. When you see the list "people who bought this gewgaw also looked at this lot" on the bottom of a page, chances are that's Mongo telling you, and who cares if it's right? What matters is you didn't have to wait an extra ten seconds for the stupid page to load.
Still! Every time you order from Cisco, the order goes through a Mongo store. Since they have been using Mongo for a long time, they either make durability in their application code -- which, dangerous secret, is much easier than doing it in the DB -- or just aren't too arsed about it. (I'm betting it's the latter.)