It allows you to write code like this:

    val query = "Brian"
    val result = for {
      db <- connectToDatabase
      user <- userFromDatabase(db, query)
      friends <- friendsFromDatabase(db, user.friends)
    } yield friends

An example from the Play! Framework for form submissions:

    def submit = Action { implicit request =>
      contactForm.bindFromRequest.fold(
        errors => BadRequest(html.contact.form(errors)),
        contact => Ok(html.contact.summary(contact))
      )
    }

if (typeof result === Error) {

The problem is that if you count on the caller to check on the error value for the data, he might forget to do that. And the code works just fine in testing, and it seems like it works. But in the error case, we merrily continue on and try to pass the error around as if it were data.

When we return two values, error and data, then the developer is forced to think about the fact that the result could be an error, and think right then about what should happen. THis is a good place to be thinking about it.

Also, the developer may not even know at-a-glance that the function could sometimes return an error, unless consulting the documentation.

Or more succinctly: it's not about making the code easier to write (which the version you mentioned does); it's instead about making it easier to do the right thing.

  foo.doSomethingAsync(function(result) {
    ...
  }, function(err) {
    ...
  });

    def parseData(data):
        return doManyFancyThingsWith(data)
    
    def parsedAsyncResult():
        return asyncResult().addCallback(parseData)

    def callback(data):
        print 'Parsed data:', data
    def errback(err):
        print 'Oh no, something went wrong!'
    parsedAsyncResult().addCallbacks(callback, errback)

    try:
        data = doManyFancyThingsWith(asyncResult())
        print 'Parsed data:', data
    except:
        print 'Oh no, something went wrong!'

  try:
      data = doManyFancyThingsWith(yield asyncResult())
      print 'Parsed data:', data
  except:
      print 'Oh no, something went wrong!'

  foo.doSomethingAsync(function(result) {
    ...
  }, {
  error: function(err) {
    ...
  },
  afterward: function(then) {
    ...
  },
  evenLater: function(wat) {
    ...
  }});

Besides, that's still only one function call. When you need to call many async things one after the other (that's what i meant by "chaining"), that nested callback-based code becomes much much convoluted than the analogous "normal" return-based code.

With promise monads [1] or some sort of language transformation that lets you write code that looks sequential but then is transformed into chained callbacks, you can basically get rid of all those extra callback functions and their associated complexity (i.e. all the mangled "success" and "error" callbacks from chained async functions) and have code that looks normal function calls one after the other. Notice that pufuwozu's example had three consecutive async calls, but it didn't need to create all the callback functions to pass between the calls.

[1]: This is a nice little spec for chainable promises: http://wiki.commonjs.org/wiki/Promises/A. And here's a post that explains how they are used: https://gist.github.com/3889970