This discusses some of the rationale:

https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/

In general, we believe code review is most effective when commits are very small.

We'd eventually like to retain the local commits as well (see T1508), but this isn't a priority.

This may also be informative:

https://secure.phabricator.com/book/phabflavor/article/recommendations_on_revision_control/

The principles you have written down about small commits, one idea = one commit, etc. make perfect sense, it's the same thing we are advocating in our company.
But what I don't understand is how this maps on the issue that Schevalter is highlighting: if you have nicely split up a bigger idea into smaller cohesive ideas, each with a separate commit, how should one send reviews for the whole?
My impression is that you are then launching different 'arc diff's for the different commits, but this is quite some overhead if you have more than 3 commits...

My impression is that you are then launching different 'arc diff's for the different commits, but this is quite some overhead if you have more than 3 commits.

Yes -- at least in this project, we'll send a separate review for each commit.

There is no automated way to unbox a stack of commits into separate reviews. This has come up occasionally in the past, but there's very little real demand for it. I personally send them as I go, and do not subjectively experience the overhead to be significant.

I made about 1,500 commits in the last year, and this overhead is no more than a few seconds per commit to switch branches (often, commits are not stacked, so there is no overhead). We will probably support some kind of "submit one review per commit for all commits in this range" feature eventually, but I think it would be rarely used in the wild.