The answer to that is fairly simple: main memory is glacially slow compared to the CPU. To quote from another question in a related area, approximate speeds for a modern CPU are:
L1 CACHE hit, ~4 cycles
L2 CACHE hit, ~10 cycles
L3 CACHE hit, line unshared ~40 cycles
L3 CACHE hit, shared line in another core ~65 cycles
L3 CACHE hit, modified in another core ~75 cycles remote
L3 CACHE ~100-300 cycles
Then, do the math against the DRAM vs a 2.5GHz CPU: for a single cycle the 800MHz you are talking ~ 3-4 CPU cycles. Actual timing of memory access is more complex, but adds up to a lot. The 800MHz RAM there is going to be something like 5-5-5-16, or 124 CPU cycles.
That is still in an ideal world, too: once you add in bus bandwidth, memory contention from multiple accesses to the same chips, cache overheads, and everything else you are talking about access to main memory being thirty to fifty times slower than accessing data in cache.
Disk is, of course, insanely slower. In the analysis of this problem, the question is if the performance cost - RAM that is 75% the speed - is worth the benefit - caching ~ 70% of the data ahead of disk.
To answer the question about where else you run into this: the most common place would be your graphics card, where memory bandwidth is one of the significant constraints in overall fill rate. Improvements there help substantially in increasing overall polygon count in games, etc.
Otherwise, you run into this every day, but only in small ways. You pay that 30-fold cost to write data out to DRAM, and can absolutely see and measure than in all sorts of software that ends up showing a huge performance cliff as the input size increases. Video compression and image processing are common places that this consideration can result in visible performance changes.
