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

завязывание на другие компоненты является unix-way, а не плохой практикой, а тут колхозят explorer.exe

Каталог - это базовый функционал интернет-магазина. Разумеется, если речь не идет об LP с 2-3 товарами.
Как правило, необходимость добавления магазина возникает в b2b: сделали сайт-каталог продукции, спустя время, если сайтом занимались, приходит понимание, что можно увеличить его отдачу, добавив функционал формирования и оформления заказа.
В первую очередь, это касается дилерских продаж: вывели номенклатуру списком, фильтры-автокомплиты, и сиди себе набивай заказ.

Ну, проект всегда следует строить с прицелом на дальнейшее масштабирование.

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

Вот, кстати, отличный пример анти-юзабилити: http://mta-industry.ru/service#tech-support-entityform-edit-form

А на картинке как раз нет переноса лейбла, он просто продублирован в плейсхолдере
Плохо это тем, что когда нет лейблов, и юзер ставит фокус на поле - он не понимает, что ему надо туда вводить. Особенно, это усугубляется на этапе валидации - допустим, юзер ввел телефон в поле имя, в котором допустимы только буквы. И пока он не очистит поле, он не поймет, что это поле для ввода имени.

Перенос лейблов в плейсхолдеры - одна их наихудших практик UI

https://developer.mozilla.org/ru/docs/Web/HTML/Element/input#attr-placeh...

This attribute applies when the value of the type attribute is text, search, tel, url or email; otherwise it is ignored.

Вот при каждом добавлении поля - начнется беда, т.к. каждое поле - это 2 таблицы в БД: с текущими значениями и с ревизиями (даже если они отключены). И если добавить поле на одном из сайтов, то в базах других сайтов таблицы не создадутся, а дальше все зависит от того, являются ли таблицы с настройками полей общими. Скорее всего, они должны быть общими, т.к. некоторые поля надо делать общими на разных сайтах, иначе зачем тогда вообще объединять их.

Разделение контента по доменам, в т.ч. мультидоменный контент с canonical на заданный, разные меню для доменов, индивидуальные настройки для сайтов - тема оформления, название-слоган-логотип, доступные языки и т.д, отдельные пользовательские роли/права доступа подоменно.

Не советую делать через общие таблицы. Делал так еще на семерке, довольно-таки стрёмное решение.
Лучше - одну базу и модуль Domain Access

Я просто закомментил в field_slideshow.info данные о релизе. Сколько там той семёрке жить осталось.

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

вспомнилось:

я печатаю со скоростью 5000 знаков в минуту, правда такая фигня получается

Нормальные не берутся за проекты с бюджетом $250/мес.

Битрикс плох, тут без вариантов. Но, стоит заметить, разработка на нем пользуется спросом в РФ, и умея в Битрикс, без куска хлеба точно никогда не останешься. Так что знать его хотя бы в общих чертах - будет небесполезно.
Стоит ли идти в вебстудию - да. Но не за Битриксом, а за опытом работы в вебстудии. Прочувствовать на себе как строится процесс командной разработки - все эти таски, пулл-реквесты и код ревью - догогого стоит.
Технологию можно изучить, а опыт - изучить нельзя, его можно только приобрести со временем.

Вьюс вывести в блок, а блок уже вставлять в меню. Во всякие мегаменю точно можно вставлять блоки, в суперфиш - не уверен, надо проверять.

Я бы выкинул taxonomy_menu и рендерил меню таксономии через views_tree
Аргументы:

С семерке он есть для обратной совместимости и миграции с D6

и как юзеры будут подтверждать свой email?

я бы еще добавил проверку, что массив class существует:

Раз кеш был отключен, то дело не в его ребилде. Но включить все равно не помешает.
Если это одностраничник со статикой - то можно и побольше срок жизни кеша сделать.

Что непонятного?

А что со сроком жизни кеша?
Может, периодическая задержка связана с тем, что кеш просрочен, и в этот момент ребилдится заново?