Well given that we're talking specifically about reverting the merge when something goes awry, firstly you want that history preserved so that you can re-start work on it, potentially without pulling in all of the changes in one go; and secondly so that you can determine the precise point at which the problem happened.
Consider the difference between:
* Well we need to revert this because it's causing problems, but now we've got one massive chunk of several day's work to pick through.
…vs:
* Well we need to revert this, but we can see that the problem was specifically commit xzy, so let's yank that, do it a different way, and merge the result.
Aside from that, it can be very useful to see the individual steps in implementing a feature for a variety of reasons. Given that a --no-ff merge achieves everything you are aiming for with the squash, why wouldn't you pick the more flexible approach?
Consider the difference between:
* Well we need to revert this because it's causing problems, but now we've got one massive chunk of several day's work to pick through.
…vs:
* Well we need to revert this, but we can see that the problem was specifically commit xzy, so let's yank that, do it a different way, and merge the result.
Aside from that, it can be very useful to see the individual steps in implementing a feature for a variety of reasons. Given that a --no-ff merge achieves everything you are aiming for with the squash, why wouldn't you pick the more flexible approach?