My main point was that promises represent an entirely new coding style, which pantomimes the familiar try/catch/return, but isn't quite the same. So you have to learn two systems.

For instance, the following three blocks are not equivalent, but they're easy to mix up:

  // executes serially
  promise.then(function () {
    return somethingThatReturnsAPromise();
  }).then(...)
  
  // doesn't wait for something() to return
  promise.then(function () {
    somethingThatReturnsAPromise();
  }).then(...)
  
  // executes something() immediately
  promise.then(somethingThatReturnsAPromise()).then(...)

With synchronous code, it's obvious what order things happen in, because you just read top to bottom. But yeah, I do agree that arrow functions make it a bit nicer. :)

That's more a property of arrow functions than of promises, though, isn't it? We could expect any promise-equivalent to look OK with arrows, too. Callbacks are certainly more palatable in coffeescript, for example.

Well yes, arrow functions are the magic ingredient.

But the point is that with them you can express custom control flows trough custom functions instead of built-in syntax without much of a loss of readability.

So we don't necessarily have to wait for ES7. We already have alternatives. Some people have also built async from generators (yield) + promises. So that's another ES6 alternative.