MapReduce diverges from most divide and conquer systems in a fairly fundamental way, but one that's so simple that many people almost miss it. The real genius of it is in tagging the intermediate results.
In a typical (previous) divide and conquer system, you divide the work up serially, execute work packets in parallel, and then merge the results from that work serially again.
In MapReduce, you divide the work up serially, execute work packets in parallel, and tag the results to indicate which results go with which other results. The merging is then serial for all the results with the same tag, but can be executed in parallel for results that have different tags.
In more previous systems, the merge step became a bottleneck for all but the most truly trivial tasks. With MapReduce it can still be if the nature of the tasks requires that all merging be done serially. If, however, the task allows some degree of parallel merging of results, then MapReduce gives a simple way to take advantage of that possibility. Most other systems do one of two things: either execute all the merging serially just because it might be necessary for some tasks, or else statically define the parallel merging for a particular task. MapReduce gives you enough data at the merging step to automatically schedule as much in parallel as possible, while still ensuring (assuming you haven't made mistakes in the mapping step) that coherency is maintained.
Also note that in MapReduce, it's implicit that all of the steps can be recursive, so I might have an initial mapping step that breaks a big task up into 5 smaller tasks that can be executed in parallel -- but each of those might (in turn) get mapped out to a number of other smaller parallel tasks, and so on.
This leads to a tree structure on both the mapping and the reducing sides to quickly break a large task down into enough pieces to take advantage of many machines.