Lambda the Ultimate

I was so asking for this...

That's slightly unfair -- for example, they do back up their recommendations for implicits (for example), and their recommendations about using immutable collections (again, for example) -- just to pick two random examples.

(Of course it's not nearly as detailed as Effective Java, but...)

Yeah, it's a bit of an odd choice. I actually think the term monad is kind of terrible: it sounds far more abstruse than it really is, and doesn't give you a clue as to what it's about. I quite like F#'s choice of the term "workflow", which actually gives a decent feel for what it's about and makes the idea seem ordinary and approachable (which it is).

But I much prefer the term "bind" to "flatMap". The nice thing about bind is that it reminds you of the relationship between monadic bind and let binding, which is an important connection.

I've found that explaining it to people as mapping and then flattening the nested structure is enormously easier to understand what's actually happening. I think that to someone seeing them for the first time, "bind" is about as useful as "monad" in explaining the structure of the computation.

"Map, then flatten" is not a good description of the bind operation for all monads (although I agree it's a nice intuitive place to start). So if you rename bind to flatMap, you may end up with a bunch of things called flatMap that seem to have extremely obscure semantics.

Actually you can define map and flatten for any monad. Whether that is more easy to understand than bind I leave to the psychologists.

Sure, but while map is usually pretty intuitive, 'flatten' is often non-obvious. But I do see your point. I guess I don't know whether it's easier to understand or not.

In the case of the IO monad, at least, I think bind is a lot more intuitive than join. I guess I feel it's easier to see how bind generalizes beyond "collections", while "join" (and thus "flatMap") has a very collection-centric intuition. But, point taken... maybe it's just me.

Strange advocacy: each example with "flatMap" was immediately followed by the same example with "for" instead, and IMHO the example with "for" was more readable.
Is-there some use of "flatMap" where "for" cannot be used?

The for comprehension acts as sugar for a chain of flatMap, filter and map calls, so no, there isn't.