Да спору нет, что языки с динамической типизацией и поиском переменных/полей по имени (с которым в реализациях борются, но который нельзя побороть до конца) -- принципиально медленные и плохо поддаются оптимизации, даже если их компилировать в нативный код. Да, JS -- очень скверный ассемблер, т.к. вообще не для этого разрабатывался. :-) И тем не менее, уже всего-то -- пять раз, если верить этой статье. А для многих приложений даже это близко к приемлемому уже сейчас. Жаль, что разумной альтернативы JS, которая была бы настолько же переносима, пока нет. Но, может быть, ещё будет... А пока есть то, что есть, и уже с ним результаты довольно интересны. Тенденция очевидна. И если подобный высокоуровневый ассемблер нужен (а он нужен, единое окружение для исполнения программ -- это ПРАВИЛЬНО), он появится и станет стандартом де-факто. И уж за десять лет что-нибудь должно, просто обязано созреть. Так что всё будет. Но, конечно, не сразу. :-)

К слову сказать, для того, чтобы сделать JS намного более пригодным на роль ассемблера нужно ввести в язык всего несколько изменений, всего несколько новый конструкций. Операции с полностью явным указанием типов. Особый вариант поиска переменной/поля, который целиком бы рассчитывал на то, что объект или область видимости, в которых поле ищется, не имеет динамически добавленых по сравнению с изначальным шаблоном (который, собственно, тоже надо декларировать -- это ещё одна конструкция) полей. Всего три добавления, причём неважно, насколько новый синтаксис будет удобен для использования человеком, это всего лишь средство сделать JS пригодным на роль промежуточного переносимого языка, на котором будет генерироваться эффективный код. Все эти сборки или не сборки мусора, всё это пройдёт, уж эти проблемы решатся непременно, они уже во многом решены. Настоящее зло -- работа с любым типом данных ТОЛЬКО как с неизвестным и потенциальная необходимость поиска по имени.