Async/await это шаг назад для JavaScript'a?

Мы не определяли промежуточные переменные для хранения этого состояния

const a = await getA();
const b = await getB(a);
const c = await getC(a, b);

1. промисы не решали в понятном виде большое количество проблем. Например — использование while или switch-case внутри логики (а особенно все вместе).
2. правильно воспринимать их не как сахар, а как специфическую инструкцию, которая делает 2 отдельных вещи: уступает поток исполнения и ожидает выполнения результата. Мы можем использовать ее и для того, и для другого.
3. async/await действительно является шагом назад под давлением внешних факторов, но не потому что она не функциональная, а потому что реализует подмножество функционала функций-генераторов, и не имеет особого смысла (кроме возможностей для подсветки и простоты самой по себе). Я бы предпочел видеть синтаксис вроде Promise.generator(function() {}), он бы дал куда больше гибкости и возможностей для тестирования — как минимум за счет инструкции yield.
4. то, что вы любите функциональное программирование, не значит, что его любят все. JS пытается стать универсальным языком, а не вторым OCaml.

Изучаем новые слова, такие как функторы, монады, моноиды и вдруг наши dev-друзья начинают считать нас крутыми, потому что мы говорим эти странные слова довольно часто!

Ведь мы писали обычный императивный код, как в 80-х годах, обрабатывали ошибки с try/catch, как в 90-х годах

  function subscribe(listener) {
    if (typeof listener !== 'function') {
      throw new Error('Expected listener to be a function.')
    }

    let isSubscribed = true // мутабельность

    ensureCanMutateNextListeners()  // нет чистоты
    nextListeners.push(listener)  // мутабельность, нет чистоты

    return function unsubscribe() {
      if (!isSubscribed) { // нет чистоты
        return
      }

      isSubscribed = false // мутабельность, нет чистоты

      ensureCanMutateNextListeners() // нет чистоты
      const index = nextListeners.indexOf(listener) // нет чистоты
      nextListeners.splice(index, 1) // мутабельность, нет чистоты
    }
  }

function doSomeWork(request) {
    // код...
    // где в середине
    if (request == null) {
        return;
    }
    // где-то в конце, doPost возвращает Promise.
    return request.doPost(/**...*/);
}

В Scala (и scala.js) существуют и промисы (только используется другой нейминг, вместо Promise они называются Future) и async/await. И все предпочитают использовать именно промисы (фьючи). Причина в том, что async/await создает ложную иллюзию синхронности происходящего. Это может привести к тому, что синхронная и асинхронная логика будут смешаны вместе и в какой-то момент await потеряется перед асинхронной функцией. Или наоборот, await "на всякий случай" будет приписываться везде, даже если функция не асинхронная. При использовании промисов синхронные и асинхронные потоки явно отделены друг от друга. Глазами сразу видно, где тут у нас асинхронное выполнение, а где синхронное. И это потенциально более безопасно и не приведет к ошибкам, которые я выше описал.
Чтобы асинхронный код не превращался в кашу в Scala используется for-comprehension. И такой асинхронный код выглядит почти как синхронный, но при этом явно видно, где тут синхронные части, а где асинхронные.
В Scala/Scala.js коде пример выше выглядел бы примерно следующим образом:

def handleRequestArrows(user: User, sender: ResultSender): Future[SendingResult] {
    val res = for {
        _ <- isUserValidAsync(user)
        (data, rate) <- Future.sequence(Seq(getUserDataAsync(user), getRateAsync("service")))
        savedData <- updateUserDataAsync(user, updateData(data, rate))
        sendingResult <- sender.send(savedData)
    } yield sendingResult
    res.andThen { // обычно это делают на уровне выше, но я добавил сюда, чтобы не отступать от примера
        case Failure(e) => logger.log("An error ocurred", e)
    }
}

Код вполне наглядный. Видно, что за чем идет. Если какой-то шаг вернет ошибку, то выполнение всего блока for-comprehension прервется.