What is the novelty in MapReduce?
I can not help but think: this is divide &amp; conquer, plain and simple!


M/R is not divide &amp; conquer. It does not involve the repeated application of an algorithm to a smaller subset of the previous input.  It's a pipeline (a function specified as a composition of simpler functions) where pipeline stages are alternating map and reduce operations.  Different stages can perform different operations.




  So, is there (conceptual) novelty in MapReduce somewhere, or is it just a new implementation of old ideas useful in certain scenarios?


MapReduce does not break new ground in the theory of computation -- it does not show a new way of decomposing a problem into simpler operations.  It does show that particular simpler operations are practical for a particular class of problem.



The MapReduce paper's contribution was 


evaluating a pipeline of two well understood orthogonal operators that can be distributed efficiently and fault-tolerantly on a particular problem: creating a text index of large corpus
benchmarking map-reduce on that problem to show how much data is transferred between nodes and how latency differences in stages affect overall latency
showing how to make the system fault tolerant so machine failures during computation can be compensated for automatically
identifying specific useful implementation choices and optimizations


Some of the critiques fall into these classes:


"Map/reduce does not break new ground in theory of computation."  True.  The original paper's contribution was that these well-understood operators with a specific set of optimizations had been successfully used to solve real problems more easily and fault-tolerantly than one-off solutions.
"This distributed computation doesn't easily decompose into map &amp; reduce operations".  Fair enough, but many do.
"A pipeline of n map/reduce stages require latency proportional to the number of reduce steps of the pipeline before any results are produced."  Probably true.  The reduce operator does have to receive all its input before it can produce a complete output.
"Map/reduce is overkill for this use-case."  Maybe.  When engineers find a shiny new hammer, they tend to go looking for anything that looks like a nail.  That doesn't mean that the hammer isn't a well-made tool for a certain niche.
"Map/reduce is a poor replacement for a relational DB."  True.  If a relational DB scales to your data-set then wonderful for you -- you have options.