Василий Назаров

План слабо возможен в том смысле, что современная веб-разработка
1. Очень объёмна с т.з. нужных знаний/умений
2. Очень динамически развивается (особенно фронтовая часть)

Но в вашем конкретном случае просто
1. Найдите тему для веб-приложения, которое вы хотели бы создать
2. Начинайте учить те технологии, которые для реализации понадобятся "по ходу" ("по ходу" - это "по ходу дела", не дурацкий жаргонизм вместо "похоже")

Скорее всего, лучше всего двигаться сюда https://ru.vuejs.org/v2/guide/

Это, конечно, радикальное мнение, и пока не самое популярное.
Но.
Самые лучшие проекты на Angular - это те, которые уже отправлены в корзину.

Сделать общий api.domain.tld, брать CORS-аяксом с withCredentials из любого места, сессию стандартно, в куках?

вычитал чтобы стать хороший фронтом,надо знать хотя бы минимум nodejs

В этом контексте, видимо, подразумевается, что вы будете использовать Node как инструмент для автоматизации разработки фронта. Gulp и т.п.
А если имелась в виду серверная разработка, то фронт тут не при чём, это уже фулстек. Что бывает востребованно.

зачем [..] такие монстры

Очень нередко - только для того, чтобы поднять ЧСВ "разработчика".
Но иногда фронтовые фреймы полезны, хотя мало (или совсем нет) приложений, где нельзя обойтись простым и компактным Vue против перенавороченных Rеact или, тем более, Angular.
Но

получается что вы пилите уже не только интерфейс но и бизнес логику?

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

слышал, что Angular позволяет делать большее в огромных проектах

Говорят, в Москве кур доЯт.
Во-первых, делать большее позволяет голова, а не мантры "Angular-Angular-Angular".
Во-вторых, вам до "огромных проектов" как до Китая в неудобной позе.
В-третьих, Ангуляров - два, и второй (он же 4-й) почти никому не нужен, а 1-й даже самими его разработчиками признан неудачным.
В-четвёртых, если работодатель/заказчик не хочет Vue, который на сегодня однозначно лучше и React-a, и Angular-а - стоит ли идти к такому работодателю?
Более аргументированно тут.

Если вариантов мало (да, мало - это " как хотите"), то можно списком.
Если много, и инвариантно - лучше структурой.
Развёрнуто:
Ф-ция вызывается почти всегда как f(x), реже - как f(x, y), и почти никогда как f(a, b, c).

Не парьтесь

В программировании вообще две беды: актуальность кэша и как назвать переменную

Кто бы указал первоисточник - был бы благодарен.

а вдруг я что-то поправить прям на серваке захочу

Кто так говорит, или профессионал высочайшего класса, и прекрасно понимает, чем это грозит, как потом эти правки перенести в репозиторий, когда это делать действительно необходимо/дешевле, как застраховаться от проблем, которые такие правки вызывают, и, по идее, должен быть готов взять на себя ответственность за последствия. Т.е. в этом случае вам вообще не стоит беспокоиться по этому поводу.
Или наоборот - совсем не профессионал. Что вам в этом случае делать в такой команде - вопрос философский.

Почитайте вот этот вопрос.
https://toster.ru/q/441372?e=5485607#answer_item_1...
В двух словах:
SPA и SEO в общем случае несовместимы, поэтому, если нужно и то, и то, делается две работы: одна - SPA, вторая - SSR.
SSR для Vue.

Не получится ли что я "притяну за уши" реакт?

Ну, во-первых, действительно, примерно так и получается с виду.
Во-вторых, как выше писали, можно подключить SSR, но это => на сервере Node.JS (без Ноды будет ещё то извращение).
В-третьих, есть возможность делать на сервере "обычный" Web 1.0 функционал (все страницы отдаются сервером с перезагрузкой), но при этом на фронте уметь реактом эти же страницы перерисовывать, получая с бэка только данные.
По 3-му варианту вам нужно будет дописать несколько контроллеров, условно дублирующих основные, вроде такого:
- /catalog/category/id/page/n - отдаёт всю HTML-страницу
- /api/v1/catalog/category/id/page/n - отдаёт только JSON-массив товаров на странице

Странно, что у вас вообще этот вопрос возник, ведь по идеологии Laravel => Vue.

Если зацепиться за "полностью" то ответ будет "нет, полностью - не обязательно".
По крайней мере, чаще всего вполне достаточно знать $,ajax(), $(e).fadeOut() и кучу всего подобного, что даёт jQuery, вместо того, чтобы курить мануалы по тому, как это же сделать на Vanilla.JS.
Но "знаю jQuery, и не знаю JS" - это примерно как "умею рулить, но не умею ездить".

На будущее: никогда не используйте несколько одинаковых id, это бессмысленно.
id - уникальный идентификатор

во многих вакансиях я вижу также такие требования, как

У некоторых работодателей и такие требования бывают.

почему, если он такой крутой, то нет хостингов на его базе?

Примерно потому же, почему нет хостингов на Java, C++, Ruby, ...