Вы задаете очень общий вопрос, на который полно информации в интернете. Например вот статья: https://habr.com/post/326304/ .

Вам не понятно в чем профит?
- меньше ошибок при разработке
- более адекватный intellisense
- намного проще рефакторить
- использовать сторонний код (тайпинги могут (но не должны) частично заменить доки)
- генерация документации https://typedoc.org/
- возможность вообще описать где-то сущности, а не опираться на их создание в коде
и много всего еще.

Или вы не согласны, что профит есть? Тогда аргументируйте с чем вы не согласны (относительно множества источников в интернете).

Дисклеймер:
С веб-воркерами (и чем-то подобным) все и так понятно, поэтому далее я пишу вне их использования

Ответ на ваш вопрос сильно зависит от понимания заголовка. Если мы говорим про браузер или какую-то его часть - то вполне вероятно это действительно работа в отдельном потоке. Только это работа браузера, а не javascript. Вот например статья про node.js https://codeburst.io/how-node-js-single-thread-mec... (достаточно прочитать Top Highlight)

The main event loop is single-threaded but most of the I/O works run on separate threads, because the I/O APIs in Node.js are asynchronous/non-blocking by design, in order to accommodate the event loop.

Таким образом про node.js можно сказать, что оно - многопоточное приложение. Но вот с точки зрения javascript-а, то есть как-бы изнутри него - node.js - однопоточный. Иными словами: весь JavaScript код и в браузере и в ноде позиционирует себя как однопоточное приложение. И исполняется так же. Но какие-то операции вне языка (I/O или тот же xhr) могут быть реализованы как угодно браузером. Это строго говоря вопрос больше про устройство среды исполнения.

Я подвис, но мой ответ был, что JS можно считать многопоточным и я так предполагаю из-за наличия xmlhttprequest запросов (в простонародии ajax).

- строго говоря это не так. Хотя мне кажется это не далеко от истины. Если мы поговорим, что язык многопоточный, я думаю мы имеем ввиду, что языком поддерживается работа с потоками, а не то как он устроен изнутри или как изнутри устроена среда его исполнения. Потому как какая-нибудь сборка мусора может выполняться в отдельном потоке, но это не делает сам ЯЗЫК много поточным.

Вопрос: Относится ли WebAPI к движку JavaScript и корректно ли утверждать, что фактически xmlhttprequest выполняется в отдельном потоке от остального кода JavaScript?

- Нет. Это API которое браузер предоставляет внутрь движка. Это можно проследить взяв например node.js и сравнив с браузерным js. Так, например, в node.js доступны внутренние модули (fs, http, path etc.)., а также другие фичи, такие как process.argv и так далее, в то время как в браузере есть WebAPI, например, fetch. При этом в браузере нет require('path'), зато в ноде нет fetch.

И это при том что и браузер (chrome) и node.js работают на одном движке (V8).

В node.js нет доступа к xhr, что уже может навести на мысли о том, что это не часть движка.

Важное замечание: я думаю сравнивая node.js и браузер, можно сформировать какое-то представление о том, что из себя представляет чистый движок js, но тем не менее это не полностью достоверно. Потому как, например, и там и там есть совместимые друг с другом setInterval и setTimeout, однако (если мне не изменяет память) они не входят в движок.

Если хочется четче понять где проходит граница, но не так сильно чтобы читать спеки - можно попробовать встроить движок самостоятельно. V8 или SpiderMonkey (в Firefox'е) умеют встраиваться в другие приложения и если встраивать их самостоятельно - и API внутрь движка (причем конкретной его реализации, а не абстрактного понятия) нужно будет прокидывать самостоятельно - тогда можно будет увидеть, что в голом движке не будет ни setTimeout, ни alert, ни console.log, ни document ни даже require и т.д.

Прежде всего нужно понять - действительно ли быстрее?

Есть замечательный доклад на эту тему: https://www.youtube.com/watch?v=HPFARivHJRY - очень рекомендую к просмотру.

На вскидку:
- движок может выкидывать тот или иной кусок бенчмарка
- движок может реализовывать какой-либо кэш и считать один раз

P.s. в мозиле результаты другие: победил lodash, что иронично потому что у него под капотом indexOf

вероятно вам нужно что-то такое:
if (![10, 9, 8].includes(8)) ...

Судя по всему вы хотели написать
if ((8 == 10 || 8 == 9 || 8 == 8) === false) ...
В таком случае:

1) при сравнении чисел лучше использовоть строгое равенство (===):

// для адекватности примера заменил 8 на x
if ((x === 10 || x === 9 || x === 8) === false) ...

2) нет смысла сравнивать результат логической операции с false, можно просто поставить перед скобками !:
if (!(x === 10 || x === 9 || x === 8)) ...

Дисклеймер: так как вопрос скорее теоретический, я не стараюсь предоставить "адекватное" решение.
Конечно, все это нельзя использовать в реальном проекте!

Интересный вопрос.

Начнем с того, что определимся насколько критично сохранить сигнатуру функции? В зависимости от этого, решения можно поделить на 2 категории:
- где допускается изменение сигнатуры
- где сигнатура должна быть строго такой и никакой иначе

Также есть ряд решений, подразумевающий предобработку кода тем или иным путем.

Стоит оговориться, что строго говоря такую функцию в данном виде написать нельзя, потому как при вызове функции переменная уже должна быть "разименована", а значит мы так или иначе будем работать с ее значением или с какими-то косвенными сайд эффектами вызванными обращением к ней.

Сначала рассмотрим несколько решений с изменением сигнатуры: они попроще и в каком-то смысле более логичны.

есть как минимум 2 категории решений с изменением сигнатуры:
- функция будет принимать строку
- функция будет принимать функцию

При этом проблема того, что все падает до попадания в функцию, пропадает сама собой.

вот несколько решений:

1) класс решений построенный на анализе кода в рантайме:
решение заключается в том, что вызываемая функция анализирует свой код (а также код функции которая вызвала ее и т.д.)
https://stackoverflow.com/questions/2051678/gettin... вот тут есть частчный разбор такого решения.
Приводить его в виде кода я не буду :)

Плюсы:
- вроде как решает задачу
- сигнатура изменилась не сильно
Минусы:
- крайне жирное решение с точки зрения производительности
- сигнатура не та, что просили
- нельзя использовать 'use strict', так как решения возможно будут завязаны на arguments.callee.caller

Уровень безумия: достаточно безумное

2) решение построенное на том, что приниматься будет функция:
isExists(() => someVar); // такая будет сигнатура

Это решение хоть и меняет сигнатуру, но ее возможно сохранить максимально подобной желаемой

Одна из возможных реализаций:

function isExists(someVarFn){
    try {
        someVarFn();
    } catch(e) {
        if (e instanceof ReferenceError) {
            return false;
        }
        throw e;
    }
    return true;
}

Примеры использования:

function f1() {
    let x;
    console.log(isExists(() => x)); //  => true
    console.log(isExists(() => y)); //  => false
}

function f2() {
    let x;
    console.log(isExists(() => x)); //  =>  true
    console.log(isExists(() => y)); //  => false
}

f1();
f2();

Плюсы:
- плюс-минус адекватная производительность
- довольно компактно
Минусы:
- несильно меняется сигнатура функции
- api получается несколько не очевидным

Уровень безумия: почти адекватное

3) решения с использованием eval:
Суть похожа на решение #2, но с другим api:

function isExists(varName, fn){
    return fn(`(()=>{
        try {
            const nop = ${varName};
        } catch(e) {
            if (e instanceof ReferenceError) {
                return false;
            }
            throw e;
        }
        return true;
    })()`);
}

function f1() {
    let x;
    console.log( isExists('x', c => eval(c)) ); //  => true
    console.log( isExists('y', c => eval(c)) ); //  => false
}

function f2() {
    let y;
    console.log( isExists('x', c => eval(c)) ); //  =>  false
    console.log( isExists('y', c => eval(c)) ); //  => true
}

f1();
f2();

Плюсы:
- сложнее чем в №2 передать какую-то фигню
Минусы:
- сигнатура отлиается сильнее и уродливей
- сложнее / жирнее / больше чем №2

Уровень безумия: безумненько

Решения с сохранением сигнатуры:

4) магия es6 Proxies + with
класс решений строится на стратегии: слушать доступ к глобальному объекту и если он происходит и в нем нет переменной с таким именем - такой переменной нет:

const pseudoUndefined = {};

const scopeTrap = new Proxy(window, {
    has() {return true},

    get(target, prop) {
        if (prop in window) {
            return window[prop];
        } else {
            return pseudoUndefined;
        }
    }
})

function isExists(someVar) {
    return someVar !== pseudoUndefined;
}

// весь код использующий функцию должен быть обернут в такой with :(
with (scopeTrap) {

    let y;
    console.log( isExists(x) ); //  =>  false
    console.log( isExists(y) ); //  => true

}

Плюсы:
- мы сохранили желаемую сигнатуру! Ура!
Минусы:
- теперь вместо исключения будет получаться что-то совсем левое. Хорошего дебагга! :D
- накладные расходы производительности
- все нужно обернуть в with
- необходима поддержка es6+

Уровень безумия: с точки зрения реализации - задача подъемная. использовать в бою - а вы знаете толк!

Решения с предобработкой:

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

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

Плюсы: ...
Минусы: ...
(Без комментариев)

Уровень безумия: я думаю все понятно
...

есть и более сдержанные решения, например, используя compile-time можно оптимизировать предыдущие решения:

6) можно используя парсер составить дерево областей видимости (хэш-таблица [функция <-> список переменных]), привязать каждую область к функции, через позицию в исходном коде (возможно придется сохранять дополнительную информацию). А дальше все это интегрировать с решением №1.

В итоге:

Плюсы относительно (#1):
- относительно хорошая производительность
Минусы:
- сложно
- дорого
- требует compile-time

Уровень безумия: стало еще безумнее, чем было :)

7) написать (или найти) плагин для babel'я (или чего-то другого), который будет трансформировать доступ к переменным в особую функцию

Плюсы относительно (#1):
- достигнут результат
Минусы:
- требует поддержки
- требует compile-time
- упадет производительность (вероятнее всего существенно)

Уровень безумия: буднечно безумное