A few more things to add to this discussion:
1. In terms of impact, I think it makes sense to view this extension as similar to -XDoAndIfThenElse and -XLambdaCase. Both are similar in their levels of complexity and add a similar amount of syntax. Would GHC be better off without them? Or do we expect that some future version of GHC may have one or both of them on by default? I think that if we ever want to change basic Haskell syntax (such as DoAndIfThenElse and ArgumentBlock), we have to start it off with an extension.
2. Following up on that, perhaps another way to view this question is: Do we ever want this functionality to be part of standard Haskell? If not, then I would vote against this extension, because it just adds fragmentation. If there's a possibility that we may want to permanently change default syntax a la ArgumentBlock, then we have to start off with an extension. (FYI I believe it is a valid possibility, in that the extension is inherently backwards compatible -- it should not break any code if it is enabled, as it allows strictly more parses.)
3. It does make some cases cleaner. Consider the following code: [1, 2, 3] ++ concat (do { .... }). This can be written with parentheses, bit it cannot be written with $, because [1, 2, 3] ++ concat $ do { .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is sometimes annoying behaviour. (I used the list monad here just for demo purposes. I find it is more common with applicative operators.)
4. We can easily generalize this to include case, let, and so on. It was written without support for them to limit the scope of the change, rather than because it is not possible.
As an aside, my favorite comment so far is "All this because Haskellers are allergic to parentheses ~chrisdone".
-- Andrew Gibiansky