Последовательный вызов асинхронных функций

Мы же говорим об асинхронных процессах типа аякса и анимации, о которых мы никогда не знаем, когда они закончатся?

В примере из топика я наоборот нигде не вижу прямых вызовов runNext в теле функции.

Про костыль в принципе согласен, но случай, когда требуется делать столько вложенных вызовов, что можно переполнить стэк — это как минимум хороший повод задуматься над архитектурой.
То что таймер может «влезть» и нарушить последовательность — то же самое.

Как бы я реализовал твою задачу.

1. Если следовать принципам ООП, функционал работы с данными пользователя нужно разделить на 3 отдельных метода этого самого пользователя: один метод для сохранения, 2 для получения данных (т.к. типы запросов разные, соответственно и данные разные).
2. После того как функционал разделён, нужно реализовать интерфейс обмена данными. Это может быть явная передача callback-а в вызываемый метод, либо реализация событийной модели на основе наследования от require('events').EventEmitter:

function Person(){
  this.id = id;
};
Person.prototype = new events.EventEmitter;
Person.prototype.saveData = function(data, callback){
       this.saveFile( 'person_' + this.id, callback);
};
Person.prototype.getData = function(type, callback){};

Далее, нам как-то нужно реализовать последовательность вызовов методов нашего пользователя. Это будет происходить уже вне реализации Person. Для этого не обязательно явно создавать цепочку из вызовов функции wait с передачей кучи callback-ов. Вместо этого можно реализовать абстрактный конструктор, скажем, Actions, который будет менять состояние некоего объекта по заданному сценарию. Но сначала реализуем метод setState, который будет реагировать на смену состояния объекта:

Person.prototype.setState = function(state, data, callback) {
  switch (state) {
    case 'saveDataInFile':
      this.saveData(data, callback);
    break;
  }
  this._state = state;
};

На самом деле можно было бы реализовать это в виде обработчика события setState, в конструкторе Person:

this.on('setState', onSetState);

Тут уж кому как больше нравится. Код функции onSetState не должен находиться в конструкторе Person.

Конструктор Actions:

function Actions(instance) {
  var self = this;

  this.nextState  = function (error, data) {
    if (error) {
      instance.emit('error', error);
      return;
    }

    self.currentState = self.actions.shift();

    if (self.currentState) {
    /* Здесь может быть генерация события или вызов callback-а.
    К примеру, каждое действие может быть описано объектом,
    включающим в себя имя, данные и callback, если это необходимо. */
      instance.setState(self.currentState, data, self.nextState);
    /*
      Либо так, если реализуется через событие setState:
      instance.emit('setState', data, self.nextState);
      */
    } else { // Закончили цикл действий.
      delete self.currentState;
      self.callback && self.callback(data, instance);
      delete self.callback;
    }
  };
}

Actions.prototype.run = function () {
  arguments = [].prototype.slice.call(arguments);
  if (typeof arguments[arguments.length - 1] == 'function') {
    this.callback = arguments.pop();
  }
  this.actions = arguments;
  process.nextTick(this.nextState);
};

Таким образом, выполнение конкретных действий сводится к:

var user = new Person('id');
user.on('error', function(error) {}); // Обработка ошибок на любом этапе выполнения.

var userActions = new Actions(user);
userActions.run('getDataFromDB', 'getDataFromDB2', 'saveDataInFile', function(data, user) {});

Какие преимущества я тут вижу:
1. Разделение функционала => гибкость.
2. Появился инструмент последовательного изменения состояний объектов. На самом деле применений у него может быть очень много.
3. При запуске последовательности каких-либо действий не создаются дополнительных функций и замыканий, как в подходе автора блога и не только.

PS: Я никого не хочу учить. Я только описал свои мысли в слух по поводу решения конкретной задачи. Выбор всегда остается за вами. Извиняюсь за большой объем.
PSS: Код на работоспособность не проверял. Так же хочу заметить, что это не конечный результат, а лишь грубое описание смысла решения.