Прост JS - это хуйня, которая выполняется в небезопасном окружении.

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

Соответственно если мы это «пойти не так» хотим минимизировать - надо максимально сузить потенциальный радиус поражения. Собсна почему rootless контейнеры все сейчас форсят - потому что если кто то получил доступ к контейнеру, находясь внутри него - он не сможет из него выбраться.
В случае с аутентификацией в вебе можно действовать аналогичным образом. Даже если у нас говнари написали говнокод на говножаваскрипте - есть браузер, среда, в которой всё это говно выполняется. И вот он то как раз определенные механизмы безопасности предоставляет - изоляция кук, предотвращение их утекания при выполнении запросов на 3rd party домены, отличные от того где наш код исполняется и так далее. Собственно максимум в плане изоляции, который мы можем достичь - это отобрать у жаваскрипта доступ к аутентификационным данным, но оставить возможность ими пользоваться через API браузера. Соответственно задачи обеспечения безопасности ложатся не на плечи жабаскрипта, а на плечи браузера. Собственно это и делает httponly флажок для кук.
А теперь можно сравнить использование токенов из жабаскрипта vs использование кук, доступа к значению которых у жабаскрипта нет.
Плюсы токенов:
- Раз получил и могу пинать все сервисы, которые его могут принять
Минусы токенов:
- Если в коде, который написали или заюзали жс девелоперы есть точка для эксплуатации XSS - можно вытянуть токен и получить все плюсы от его использования (а именно - совершенно легитимно пинать все сервисы, которые его могут принять). Отмониторить такую херню практически невозможно. То есть ты живёшь не зная ответа на вопрос выебали тебя или нет. И у тебя нет способов дать на него ответ, потому что отмониторить это никак не получится при грамотной эксплуатации угнанного токена.

А теперь поюзаем куки.
Плюсы:
- Можем ограничить область их применения только доменом, на котором располагается приложение
- в случае XSS область поражения ограничена песочницей в виде нашего сервиса
- Хранением и обработкой аутентификационных данных (значения самих кук) занимается код, выполняющийся в максимально безопасном контексте (на сколько это возможно). Т.е. либо бэк, либо сам браузер. Всё что может сделать жс, это сказать браузеру: сделай туда вот такой запрос и приложи туда куки.
Минусы:
- для работы фронтэнда всегда требуется какой-то бэкэнд, который будет обеспечивать работу с куками и подрабатывать реверс-проксёй на полставки, т.к. доступ к фактическому значению токена (при грамотной реализации) будет только у бэкэнда (т.к. значения кук, отдаваемые на фронт должны содержать либо идентификатор сессии, либо зашифрованный токен).

Если посмотреть немного вокруг, а именно на то, куда в целом идёт индустрия, то можно заметить, что из драфта OAuth 2.1 почему-то выпилили implicit flow, как и resource credentials flow. Почему? Написано в самой спеке - передача токенов через юзерагент - это небезопасно.
И главному архитектору окты, который эту спеку пишет, совместно с чуваком, который писал спеку 2.0, я как-то доверяю больше, чем рандомным челикам из интернета.

Tldr. Адептам токенов на фронт можно кидать вот это полотно