Почему асинхронная функция работает иначе?

Большое спасибо за развернутый ответ и за то что пролили свет на ситуацию. Но в таком случае возникает вопрос, почему promisы от setTimeout выполняются последовательно при блокирующих awaitах (2 пример), причина в самой обёртке setTimeout?

Aligatro, не понимаю, что вам непонятно. Разверните свою мысль.

Ну смотрите, по идее, сам await является блокирующим и любой код после него должен исполнится только после обработки промиса await'ом.

Но в коде ниже, при использовании timeout, вызов функции с await внутри не блокирует поток, более того промисы обрабатываются в правильно порядке (сначала скрипты основного потока, потом асинхронная функция с задержкой в 1сек, после в 4).

// Исполняется после вызова лупа
let loopAsync = ms => new Promise(resolve => setTimeout(resolve, ms * 1000));

const getSomeTextAsync = async (text, time) =>
  `value - ${text} was showed with delay ${time} and while is ${await loopAsync(time)}`;

const showTextAsync = async (sometext, time) => {
	// блокирующий await
  sometext = await getSomeTextAsync(sometext, time);
  console.log(sometext);
}

// Основной поток
showTextAsync('something that works in async way', 4); // 1 вызов функции с блокирующим авейтом внутри
showTextAsync('something that works in async way', 1); // 2 вызов функции с  блокирующим авейтом внутри
console.log('something that work in main thread');

// console show
// something that work in main thread
// something that works in async way was showed with delay 1
// something that works in async way was showed with delay 4

Aligatro,

по идее, сам await является блокирующим

Ясно. В своей основе async/await имеют те же промисы, так что "блокирующее" действие await'а не распространяется за пределы той функции, где await использован. Перепишите свой код на промисах, и абсурдность ожидания "блокировки" потока выполнения при вызове showTextAsync станет очевидной.

0xD34F,
После препарирования call stack'а в консоли и повторного прочтения материала event'ам, картинка вроде сложилась.

Любая функция вызванная в основном потоке, будь то синхронная или возвращающая промис, будет этот самый поток блокировать до окончания её выполнения. Единственное что доступно разработчику, это возможность зашафлить стек вызова (например обернув в setTimeout) в котором сначала будут выполнены функции из основного потока, а после те которые придут из очереди событий от setTimeout.

В итоге получается что результаты при использования loop'ов "появляются одновременно", потому-что всё это время идёт блокирующая обработка циклов в основном потоке.
Во втором же примере setTimeout откладывает отправку простого объекта (а не исполнение блокирующего кода) плюс таймер крутится не в основном потоке, а в параллельном (webAPI). Что в итоге даёт эффект неблокирующего параллельного поведения.

Единственное остаётся вопрос, на кой чёрт поверх простой и понятной модели событийно-ориентированного подхода (которым как я понял вся эта конструкция и является) нафигачили столько абстракции и запутывающих конструкций (разве что синтаксический сахар, не более).

Еще раз спасибо за подробное разъяснение.