Obviously, if you consider this question in the context of something like Google Code Jam, then algorithmic thinking is clearly more important when having to solve algorithmic problems.
In everyday life, however, about a million other factors have to be considered as well, which makes the question much less black vs white.
Just a counter-example: If you need 200 more lines in Java, but everyone in your company knows Java, this isn't a big deal. If you could write it in 5 lines of Python or any other language, but you would be the only one in the company to know that language - it is a big deal. Such big a deal in fact, that you will not even be allowed to do so and instead have to write it in Java.
From a craftman's perspective, we always try to approach with the right tool for the job, but the word right in there is so tricky that one can easily get it wrong.
On the contrary, I found algorithmic thinking in companies to be almost absent. Only few select people possess it, whereas the average joe often already has troubles estimating runtime complexities of loops, searches, etc.
In terms of algorithmic competitions, however, my personal experience from competing in them for several years, clearly tells me that you should stick to one language. Speed is a major factor and you simply cannot afford to waste time on your tools, when you should dedicate it to solving the problems within the time limit. Also consider that writing 200 lines of Java code without thinking is still much faster than hand-crafting 50 lines of complicated python code requiring a lot of thinking, yet both solving more or less the same problem.
Oh and finally, make sure you understand the major differences between algorithmic competition code and company production code. I have seen fantastic algorithmic coders, that wrote horrible code I would not ever accept in a product.
It does make sense to me that this makes it faster to solve a problem if the two halves takes less than half the work of dealing with the whole data set.
That is not the essence of divide-and-conquer algorithms. Usually the point is that the algorithms cannot "deal with the whole data set" at all. Instead, it is divided into pieces that are trivial to solve (like sorting two numbers), then those are solved trivially and the results recombined in a way that yields a solution for the full data set.
But why not split the data set in three parts? Four? n?
Mainly because splitting it into more than two parts and recombining more than two results
results in a more complex implementation but doesn't change the fundamental (Big O) characteristic of the algorithm - the difference is a constant factor, and may result in a slowdown if the division and recombination of more than 2 subsets creates additional overhead.
For example, if you do a 3-way merge sort, then in the recombination phase you now have to find the biggest of 3 elements for every element, which requires 2 comparisons instead of 1, so you'll do twice as many comparisons overall. In exchange, you reduce the recursion depth by a factor of ln(2)/ln(3) == 0.63, so you have 37% fewer swaps, but 2*0.63 == 26% more comparisons (and memory accesses). Whether that is good or bad depends on which is more expensive in your hardware.
I have also seen many references to 3-way quicksort. When is this faster?
Apparently a dual pivot variant of quicksort can be proven to require the same number of comparisons but on average 20% fewer swaps, so it's a net gain.
What is used in practice?
These days hardly anyone programs their own sorting algorithms anymore; they use one provided by a library. For example, the Java 7 API actually uses the dual-pivot quicksort.
People who actually do program their own sorting algorithm for some reason will tend to stick to the simple 2-way variant because less potential for errors beats 20% better performance most of the time. Remember: by far the most important performance improvement is when the code goes from "not working" to "working".
Best Answer
If you're asking about the MapReduce architecture, then it is very much just a divide and conquer technique. However, any useful MapReduce architecture will have mountains of other infrastructure in place to efficiently "divide", "conquer", and finally "reduce" the problem set. With a large MapReduce deployment (1000's of compute nodes) these steps to partition the work, compute something, and then finally collect all results is non-trivial. Things like load balancing, dead node detection, saving interim state (for long running problems), are hard problems by themselves.