Not to focus too myopically on the given example, but I can’t help but wonder why it’s a requirement that the first file be handled specially? A less contrived example would make the argument more convincing.

If I wanted to compute the size of one file relative to a set, I’d probably do something like this:

  queue()
      .defer(fs.stat, "file1.txt")
      .defer(fs.stat, "file2.txt")
      .defer(fs.stat, "file3.txt")
      .awaitAll(function(error, stats) {
        if (error) throw error;
        console.log(stats[0].size / stats.reduce(function(p, v) { return p + v.size; }, 0));
      });

Or, if you prefer a list:

  var q = queue();
  files.forEach(function(f) { q.defer(fs.stat, f); });
  q.awaitAll(…); // as before

This uses my (shameless plug) queue-async module, 419 bytes minified and gzipped: https://github.com/mbostock/queue

A related question is whether you actually want to parallelize access to the file system. Stat'ing might be okay, but reading files in parallel would presumably be slower since you'd be jumping around on disk. (Although, with SSDs, YMMV.) A nice aspect of queue-async is that you can specify the parallelism in the queue constructor, so if you only want one task at a time, it’s as simple as queue(1) rather than queue(). This is not a data dependency, but an optimization based on the characteristics of the underlying system.

Anyway, I actually like promises in theory. I just feel like they might be a bit heavy-weight and a lot of API surface area to solve this particular problem. (For that matter, I created queue-async because I wanted something even more minimal than Caolan’s async, and to avoid code transpilation as with Tame.) Callbacks are surely the minimalist solution for serialized asynchronous tasks, and for managing parallelization, I like being able to exercise my preference.