Тимофей

Не существует готового универсального решения для таких случаев. Legacy это боль, понимаю, но придётся открывать документацию, разбираться и решать проблему самостоятельно.

SSR подразумевает исполнение кода vue компонентов на сервере, так что именно ssr сделать на php не получится. Для этого нужно поднимать node сервер, сделать нормальную сборку и т.п.
2 более простых варианта:
1) Использовать пререндеринг для страниц с vue компонентами, что всё равно потребует установки node сервера, но само приложение менять не придётся.
2) Тупо дублировать разметку в компоненте и на сервере.

В общем, какой-то чудесной серебряной пули, которая быстро и без геморроя решит задачу, не существует.

Именно повторить - никак. Каждый компонент должен иметь единственный элемент верхнего уровня, и с этим ничего не поделать. Так что либо через tbody, как писали выше, либо дробить на несколько компонентов, либо оставить всё в цикле template v-for.

Если не давать сторонним разработчикам вклиниваться в процесс сборки и вообще не давать возможность пересобирать проект, то силами webpack такое вряд ли можно провернуть. В webpack модули должны быть предсказуемыми на момент сборки и, насколько я знаю, динамически их загружать из внешних источников не выйдет.
Можно либо всё-таки пересобирать проект при добавлении сторонних плагинов и просто подгружать все плагины из определённых папок (с помощью require.context), либо писать собственный динамический загрузчик.
Передача зависимостей плагинам - вообще не проблема при любом из подходов. Просто каждый плагин должен иметь какую-то функцию инициализации, в которую вы можете передать нужные зависимости в качестве аргументов. При желании можно даже какой-нибудь DI замутить.

1. Для начала по SSR не нужно заморачиваться - пускай рендеринг всегда исходит из того, что пользователь не авторизован. Всё остальное можно подгрузить на клиенте при необходимости.

Какой порядок аутентификации нужен

- довольно странный вопрос, так как это решать вам в зависимости от того, какие условия задачи :) Предполагая, что вам нужно узнать, какие есть варианты, могу сказать, что в общем их 2 - стандартная для сайтов история с куками и сессиями или получение токена и дальнейшая авторизация по нему, то есть стандартная история для всяких REST API.
2. Если имеется в виду stateless авторизация на клиенте через OAuth, то есть замечательная библиотека для этого. Если не хочется тянуть такую большую зависимость, то можно и самому реализовать - там всё довольно просто. Могу подсказать конкретнее, если интересно. На бэкенде можно взять готовое решение, коих куча для любого языка/фреймворка/CMS.
3. Тонкостей особо нет. Получил токен или куку сессии и всё. Дальше уже всё зависит от того, что конкретно нужно реализовать.

Всё, что касается процесса подтверждения email относится к бэкенду, так что тут всё стандартно, и SSR ничего не меняет. Опять же, есть куча готовых решений для любой платформы. OAuth можно тоже полностью отдать бэкенду, но тут нужно понимать, что тогда не получится этот бэкенд использовать для stateless API.

Вот это должно решить проблему. Там примеры с параметрами пути, но с query тоже должно сработать. В любом случае, если не сработает beforeRouteUpdate, то watch $route точно сработает.

Можно использовать такой или такой подходы.

Можно попробовать вообще инициализировать роутер после проверки авторизации и, скажем, добавлять туда только форму авторизации по любому пути.

Вообще, сам вариант "запустить компонент до того, как сработает роутер" неверен с точки зрения архитектуры. Роутер всего лишь подсовывает компонент по определённому пути, то есть до того, как роутер засунет компонент, в DOM нельзя выполнять код этого компонента. То есть посыл вашего вопроса неверен в корне, нужно решать проблему другим путём.

Если вопрос именно в том, чтобы использовать PostgreSQL с нодой, то проблем никаких - есть sequelize, waterline и, думаю, еще много модулей для удобной работы с базой и ORM. По скорости выигрыш тоже будет скорее всего. Ну а в остальном слишком много "но" и "если", чтобы можно было однозначно сказать, стоит ли это делать или нет.

Можно ли сделать семантически-адаптивную и бла-бла-бля своими руками

Можно, ибо разработчики существующих решений тоже делали это, очевидно, своими руками.

но я хочу понять и научиться делать собственноручно

Конечно, делай, раз хочешь понять и научиться. В чем вопрос-то?

Куда смотреть, статьи,книги,советы

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

Еще хотел бы узнать нужна ли галерея для мобильных устройств?

Ты бы пользовался галереей на своем мобильном устройстве? А целевая аудитория сайта? Только у нее есть ответ на вопрос.

Посадочные страницы с точки зрения верстки принципиально ничем не отличаются от любых других. По flex'у выше ответили.

Такого в ангуляре нет, можно только сделать как-то так:

<div ng-hide='editMode'>{{content}}</div>
<div ng-if='editMode' contenteditable>{{content}}</div>

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

function Base() {
	var el = $('<div></div>');
	// ...
	
	return el;
}

function Sub() {
	var el = Base();
	// ...
	
	return el;
}

Можно на один и тот же элемент вешать много обработчиков одного и того же события, jQuery гарантирует их выполнение в том порядке, в котором обработчики задаются. То есть можно просто сделать так:

$( "#target" )
    .click(function() {
        fun();
    })
    .click(function() {
        afterFun();
    });

https://www.phusionpassenger.com

Попробуй сделать функцию, по аналогии с linear-gradient из nib (там снизу на странице)