DollyPapper

Давайте так. Никто не знает. Возможно вам за всю жизнь ничего не пригодится. А возможно завтра нужно будет поддерживать низкоуровневый код. Мне недавно нужно было реализовать алгоритм обхода дерева, хотя я веб разработчик, а им как бытует мнение в интернете - "алгоритмы не нужны". Изучайте, а не задавайтесь вопросами - "надо мне это или нет". Если вы еще не работаете в индустрии, и только собираетесь искать первую работу, то отдавать предпочтение изучению низкоуровневых вещей я вам не советую, много времени уйдет в пустую. Если вы уже практикующий разраб, тут на ваше усмотрение. Яб учил.

Если конкретно по JS и любите видеоформат - ТТимур Шемсединов. Лучше наверное сложно найти. Если по книгам любите, то тут уже сложнее. Не потому, что их нет, а потому что их дохрена. Если интереснен формат обучения по книгам, напишите - накидаю список.

Ну всё логично. Для того кода тип которого мы можем знать заранее - раннее (статическое) связывание. Для полиморфных позднее связывание.

При вызове

echo foo(["MyClass", "staticFunc"]); // MyClass::staticFunc

$m не определяется никак

Посмотрите через консольный гит разницу между файлами который не изменяли до и после того как сделали изменения в одном файле. Скорее всего да prettier или eslint отформатили код.

Любой, вы даже если специально самое дырявое ПО поставите вас все равно не взломают, потому, что вы

Есть хороший бэкграунд в вебразработке

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

MVC - архитектурный шаблон. Это не какая-то конкретная задача "сделать форму", "посчитать расход за месяц и сделать отчёт". Это уровнем выше и это не про код как таковой. MVC как я думаю вы уже прочитали это 3 слоя приложения (хотя M на самом деле делится на большее кол-во слоев, но сейчас не об этом). MVC был придуман как раз чтобы отделять слой представления от слоя логики, чтобы при изменении представления (которое меняется обычно чаще чем логика) не сломать слой логики, то есть для развязывания кода друг от друга. На конкретном примере можно рассказать про например "посчитать расход за месяц и сделать отчёт". Понятно что посчитать расход за месяц и сгенерировать сам отчёт это дело именно логики приложения. Как отчёт будет отображаться логику нашу волновать не должно, по этому мы стараемся максимально обособленно писать слой M и на сколько это возможно обособленно писать слой V. Логика у нас просто посчитает всё, сгенерирует данные отчёта а дальше мы уже можем из слоя логики (M) послать во вне эти данные, а слой V у нас может быть вообще чем угодно, это и десктоп приложения для винды, линукс, или это веб или еще что в голову придет. Это при условии, что разделение произведено правильно и слой M у нас действительно независим, иначе под каждый слой представления V (веб, десктоп, мобилки) мы будем кучей if проверять, где же мы сейчас хотим отобразить и городить кучу бесполезного кода. В форматах ответа на Q&A ресурсах нельзя дать хорошее полное понимание архитектуры ПО, по этому советую почитать книжку Роберта Мартина "Чистая архитектура". Для новичка скорее всего будет вообще нихрена не понятно, но сделать это стоит, что-то в голове отложится, а может и понимание придет, кто его знает.

Сервисы уровня домена это то место, где хранится бизнес логика вашего приложения (при анемичной модели, то есть той, которая не имеет в себе бизнес логики), сервисы уровня приложения, это вспомогательная логика для приложения, но не связанная с доменом. Контроллеры же - транспорт. Их задача запрос принять, обработать, вызвать кого нужно, сервисы из уровня домена, сервисы уровня приложения и т.д. и отдать ответ обратно. Логики в них должно быть по минимуму. По логике описанной вами ArticleService не должен ничего сам сохранять, это задача ИМХО StorageService, и ArticleService должен эту работу ему делегировать.

Значит и опыт только ценятся. Но не только.

Вы понимаете, что этот вопрос это вопрос о том, что будет завтра? Никто не знает, что будет завтра. Может вы придете работать, а там не будет БЭМ, значит он вам не пригодился. Но вдруг будет? Если с основными технологиями определится легко, то есть js,css, html это однозначно нужно сейчас, нужно завтра, и послезавтра нужно. С выбором конкретной технологии тоже вроде не сложно. React? Ну учите его и ищите вакансии только по нему. А вот с методологиями и прочим делом уже сложнее. Тот же БЭМ не известно. Если взять выборку из 20 компаний, 10% из них может их не использовать, или наоборот - использовать могут 90%. Тут уже ничего сказать нельзя. Какую методологию, архитектуру, сборщик, препроцессор и прочие вещи используют в компании знают только в этой компании. По этому нужно понять принципы которые за этими вещами стоят и зачем они нужны. Мне вот например совершенно похер какой будет сборщик на проекте, я просто открою документацию и понеслась. А я даже не фронт. Просто фокус в том, что я понимаю зачем они. Что вам по сути нужно чтобы использовать любой сборщик? 1) значить зачем нужен сборщик 2) знать js. Всё! Вы знаете любой сборщик, детали самого сборщика почитаете в доках при необходимости. Выберите сейчас один и изучите его. Выберите один препроцессор, поймите его. Выберите один фреймворк, изучите его. Идите на собес. Если повезло, вы работаете, если нет изучаете то на чем завалились.

понять для чего нужно и как это применить

Вот в этом весь ключ

Токены хорошо использовать там, где сервис stateless, например в микросервисах, т.к. сессии по логину и паролю горизонтально хреново масштабируются. Вы мне кажется путаете токен и обычный пароль. Логин уже должен быть зашит в токен. В вашем случае если расширять ничего не планируете, используйте обычные сессии. В случае если хотите использовать токены вам их нужно 2
1)Access токен - токен по которому юзер собственно аутентифицируется в приложении. Этот токен имеет время жизни, обычно довольно маленькое, минут 15.
2)refresh токен - по этому токену раз в 15 минут фронт посылает запрос на определенный эндпоинт и апи выдает новый access токен.
Нахрена нужен refresh токен? Очень просто. Если наш access угнали, а приложение у нас stateless, то есть мы никакого состояния и информации о заходах пользователя на сервере не храним, то мы никак не можем заблокировать данный токен, вот тут вступает в силу refresh токен. Спустя 15 минут наш access станет не валидный и клиент пошлет запрос с refresh токеном, в ответ api пришлет новый access и тот токен который у злоумышленника станет не валидный.
В вашем случае да, подойдет обычная аутентификация на куках

Технология понятие размытое. Это совокупность методов, инструментов и процессов для достижения определенного результата. Алгоритм сортировки пузырьком тоже можно считать технологией. Этот алгоритм может быть реализован в React или Angular, тогда это технология внутри бОльшей технологии.
В общем процессы, инструменты, методики и подходы в совокупности направленные на решения какой-то задачи или группы задач можно назвать технологией.
P.S.
SPA это скорее подход, который реализуется с помощью какой нибудь технологии. В контексте моего ответа его скорее нужно называть "задача"

Тык