Nexus,
Что касается вашего кода, то у меня там вся консоль засралась, я ничего не понял. Кто так тестит, что всю консоль выхлопом засирает? Убрал выхлоп, получилось примерно то же самое, что у меня. Так что не надо лапшу тут вешать

практически любой метод для работы со строками или массивами можно заменить обычным циклом, опять же вопрос удобства использования.
чем выше степень абстракции там медленнее код.
на более низкоуровневых языках можно написать код который будет гораздо быстрее, только вот нужны ли такие мучения??
зачем нужны языки с динамической типизацией если на выполнение требуется больше процессорного времени?
вопрос удобства использования =)

sortarray,
сам браузер тоже влияет, некоторые методы в FF выполняются в 5-10 раз быстрей чем в хроме, другие же наоборот.

sortarray, в Chrome в консоль выводится 4 строки, 2 из которых со счетчиком.

https://jsperf.com/ -вот хороший сервис чтобы скорость тестировать

Смотря на какой задаче. Если много операций с DOM -- вполне. Они и сами по себе самые тормозные, а тут еще медленные селекторы

Меня вывод в консоль самих колбеков не интересует, это вообще асинхронная операция. Короче, на вашем коде, который исправлен на нормальный, отслеживающий то-что нужно, addEventListener точно так же позорно слил

https://jsfiddle.net/asaLt1by/

;)

вопрос не только в самих абстракциях, но и возможности их реализации. Использование хардкорных абстракций тут только в минус.

Плюсом тут только универсальность кода при совместной разработке.
Почти все методы массивов можно написать и без нативной поддержки. Нативная поддержка нужна только для специфических фич, таких как Proxy, например

Кстати, основная задача статической типизации не в скорости, а в проверке типов на стадии компиляции. Это еще не факт, что динамика во всех случаях сольет, взять хоть те же хаскель, жаву или решетку -- достаточно тормозные языки, в целом, особенно по памяти