Основная проблема в том, что для написания программ в асинхронном стиле надо мыслить по другому.
Люди с трудом усваивают, что нельзя сделать var foo = ajax('example.com');, а уж целое асинхроноое приложение — это просто ужас.
Еще многие люди считают, что раз это (например) ДжаваСкрипт и несинхронно, то ничего кроме процедурщины уже не подходит. Немножко иначе выглядя все те же принципы остаются.
Бороться с вложеностью можно стандартными для синхронного программирования способами, например ООП. Если нам надо получить отдельным запросом топик и отдельным — комменты, то можно очень красиво сделать это так:

// обработка у нас будет выглядеть как-то так:
new Topic(id).get(function (data) {
  render(data.article, data.comments);
});

// Сам класс прост:
var Topic = function (conn, id) {
  this.conn = conn;
  this.id   = id;
};

Topic.prototype = {

  // Получены и статья и комменты:
  get : function (fn) {
    var data = {};
    var set = function (key, value) {
      data[key] = value;
      if ('article' in data && 'comments' in data) fn(data);
    };
    this.getArticle(function (article) {
      set('article', article);
    });
    this.getComments(function (comments) {
      set('comments', comments);
    });
  },

  // получение статьи из БД:
  getArticle(fn) {
    this.conn.query(qArticles, function (err, res) {
      if (err) throw err;

      res.fetchAll(function (err, rows) {
        if (err) throw err;
        fn(rows.length ? rows[0] || null);
      });
    });
  },

  // Получение комментов из БД:
  getComments(fn) {
    this.conn.query(qComments, function (err, res) {
      if (err) throw err;

      res.fetchAll(function (err, rows) {
        if (err) throw err;
        fn(rows);
      });
    });
  },
};

Методы разбиты на небольшие куски, красиво сгруппированы, вложенность — минимальная. Код читается не лучше, чем аналогичный синхронный.

На самом деле соглашусь с тем, что автор не вполне четко донес свою мысль. Сама по себе скорость Javascript в отрыве от задач, естественно, никому не важна. И да — преждевременная оптимизация это зло, грех и ересь. :-)

Но не стоит забывать что сейчас появляется все больше устройств и пользователей, которые работают не с компьютера. И если на Phenom2 многогигагерцовой частоты 7ms вместо 5ms — это фигня, конечно, то на всяких мобильных девайсах и различных встроенных решениях, которые работают на слабеньких ARM'ах или тем более MIPS'ах, разница между скоростью любого фреймворка (не обязательно jQuery), отягощенного грузом совместимостей с IE/FF2 и пытающегося объять необъятное, и нативным Javascript — огромна.

Вообще, это все крайне забавно, но на новом уровне повторяется классическая история одного байта. Только теперь уже не с ассемблером, а с Javascript (что само по себе ни в какие ворота не лезет). Одни люди навешивают «рюшечки» через jQuery и знать ничего не хотят о скорости, а другие вынуждены помнить, что применение элементу класса «hide», у которого внутри написано «display: none», вызывает reflow, а не redraw в отличие от применения инлайнового стиля с тем же самым «display: none». А redraw раза в три-четыре (в моем конкретном случае) быстрее, чем reflow, а значит окно появится на экране не через 1800-2000 ms, а в пределах 500ms (числа вполне реальные — именно столько у меня выдает Опера работающая на 400Мгц MIPS'овом SoC'е), что совершенно радикальным образом влияет на юзабельность интерфейса и его отзывчивость. :-)

Поэтому на месте автора я бы привел конкретных примеров, где скорость Javascript имеет значение, а на месте критиков не спешил бы закидывать автора тухлыми помидорами только потому, что у вас нет опыта разработки под что-нибудь кроме настольных компов. :-)

Без проблем.

$("p").click( function (event, a, b) {
 // when a normal click fires, a and b are undefined
 // for a trigger like below a refers to "foo" and b refers to "bar"
} ).trigger("click", ["foo", "bar"]);

* This source code was highlighted with Source Code Highlighter.

Что-то мне кажется, что само это выражение "метафора рабочего стола" теперь уже превратилось в некий непонятно на что ссылающийся знак. От частого повторения. Я вот вспомнил про такой досовский пакет Framework II (III, IV) от Ashton-Tate, там было что-то близкое к лично моему представлению о рабочем столе. Надо будет про это (и интерфейс нового офиса заодно) написать обязательно, спасибо Вам за тему.
Это поразительно, но оно существует по сей день - http://www.framework.com/ .