All benchmarks have been done on AWS i2.xlarge instances. They have 4 vCPUs, 30GBs of RAM and 800GB local SSDs.
It is true that we are not doing an apples to apples comparison on the 100GBs set. I think is just the opposite! We are helping MongoDB by giving it three machines (and therefore 90GB RAM!). This is specially true when the benchmark is using indexes because in this case the index can be always on RAM.
MongoDB is very fast when it has to retrieve a single document because, by design, it has an amazing spatial locality (the whole document is usually on the same page). But this feature is a weakness on aggregation queries, as they usually only care about a small subset of the document. ToroDB Stampede change that by storing your data on a relational way. Of course, as you said, MongoDB performance is horrible when it has to fetch documents from disk, but even if the documents are in memory, the same effect is expected (on aggregation queries) when data has to be move to the CPUs caches.