I was lead architect at SimpleGeo and spent most of the time working on our distributed geospatial database. I haven't looked at the MongoDB implementation in years, but at that time it was really a toy compared to what other people were doing. Basically, they used a space-filling curve to do dimensionality reduction and then stored geospatial data in the same b-tree index that they use for everything else. It's suitable for a lot of trivial use cases at scale, and even for non-trivial use cases at low data/throughput scale. But the architecture was (too lazy to determine if it still is) not suitable for large data set sizes, query throughput, or distribution for fault tolerance / improved locality, etc.

At the time it was really frustrating to here comments like yours since the MongoDB solution was superficially similar to the consumer, but was basically worse on every measurable dimension if you knew what you were doing. I hadn't heard of SpaceCurve before today, but I skimmed the linked article and some other stuff on the blog and it looks like this guy knows what he's talking about. My guess is it's a much better geospatial architecture than MongoDB's.