I would suggest that you can implement pretty much any kind of data processing you want in Map Reduce given enough time to code it, but the degree of parallelisation you will get will vary depending on what your data is and what you're doing to it.
I can imagine a simple scenario where parallelisation would be reduced dramatically. For example, a simple JOIN task with 4 mapper and 4 reducer nodes will be highly parallelised if the join keys (1, 2, 3 and 4) are evenly distributed across your mapper nodes, and there are the same number of each (4) - 4 reducers would then get an equal share of work for each join key:
Mapper 1 2 3 4 | 1 2 3 4 | 1 2 3 4 | 1 2 3 4
/ \ / \ / \ / \
v v v v v v v v
Reducer 1 1 1 1 | 2 2 2 2 | 3 3 3 3 | 4 4 4 4
However if you have a situation where most of your join keys are the same (e.g. nearly all 1s), the reducer dealing with 1s will get swamped:
Mapper 1 1 1 1 | 1 1 1 1 | 1 1 1 1 | 1 1 1 2
/ / / / /
v v v v v
Reducer 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 | 2 | nothing! | nothing!
Because 1 reducer gets totally swamped while others do nothing, you will lose most of your parallelisation while Hadoop stalls and waits for the reducer to finish.
Caveat: There may be more sophisticated Map Reduce implementations out there which deal with this kind of problem, I only know the basics of Hadoop.
Also I know this is nothing to do with statistical learning algorithms (which i know almost nothing about) but I imagine the principle is still true - some algorithms or data just won't divide into highly parallel sub-tasks.