Егор Живагин

Например bootstrap и react-bootstrap ?
В одной либе сразу две версии врятли будут жить, это имеет очень мало смысла

1. Dynamic Segments

Его можно прописать в массиве с объектами, по которому мы пробегаемся через map, а далее достать {game.path} и поместить в Link to.Верно?

-- Да, верно

Если коротко, то вы делаете один роут с path="/tovari/:id"
Все урлы вида "/tovati/111", "tovari/moytovar" попадут в этот роут
В компоненте вы можете получить id с помощью const { id } = useParams();
или напрямую из window.location.href

2. Скорее всего никак. На все ховеры реагирую через css и вам советую :)

3. Очень сложно сказать, не зная кода этих компонентов. Кажется, что можно в HOC вынести логику показа после клика, но я не уверен

Если очень коротко - потому что console.log выводит актуальное состояние объекта (на момент, в котором вы смотрите в консоль), а не состояние на момент вызова console.log.
Видите в консоли рядом с массивом на первой строчке квадратик с буквой i ? Это индикатор того, что выводимый объект мутировал

Если код клиентский, а не серверный, рекомендую в нужном месте поставить debugger; // вместо console.log(catList)

?? Вероятно, catList вам из какого-то запроса приходит? Тогда на момент первого рендера его может не быть
Достаточно поправить так:
Menu({ slug, catList = [] })

А в чём проблема с хуком? Почему хотите убрать?

Какой толк от логически правильного проектирования бэкенда, если она значительно влияет на скорость загрузки проекта (а значит на пользовательский опыт и сео-метрики) ?
Как вообще понять логическую правильность? Предположим, можно сделать ручку GET https://api-domain/groupsWithSettlements - ручка для "владений, обогащённых информацией о населённых пунктах" - это логически верно?

Разделение сущностей - это хорошо, но оно должно нести в себе смысл, решать какую-то задачу. Допустим, несколько клиентов с разной логикой, которым не всегда нужны полные данные (мобильные приложения, ещё один веб фронт, просто отдаём кому-то API, ...). Причём не гипотетических, а уже запущенных или спроектированных. Если архитектурное решение плохо влияет на проект - это плохое решение, каким бы красивым оно не казалось

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

с бэка прилетает JSON с описанием как должен выглядеть компонент

Так это же 90% любого фронтового проекта, нет? Есть у вас набор "кубиков", пишете контейнер, который получает весь JSON и в его рендере городите if-ы: "есть такие-то данные -> нарисуй такой-то компонент"

Строку из вопроса можно отрендерить через dangerouslySetInnerHtml , но реакт-компонентом это не станет и, я так понимаю, вам не это нужно

Возможно, вы сможете что-то придумать с createElement, но он собирает компонент не из строки