Robur

Смотря какие настройки и версия бабеля, вот например вариант решения:
https://github.com/mobxjs/mobx/issues/1352

Да.
mobx в большинстве случаев лучше чем redux, redux вовремя заехал на волне хайпа.

Карта не закон, это мнение человека который её нарисовал.

"необходимости" ни в чем нет - есть возможность и варианты, среди которых можно выбрать то что лучше подходит.
mobx не имеет отношения к асинхронным запросам, как и redux.
Но в силу его реактивности с ним можно использовать что угодно- от простого fetch до чего-то навороченного.
Все что способно поменять значение у поля объекта отлично интегрируется с mobx

Посмотрите как работает GraphQL + Apollo client. Особо внимательно про нормализацию и кеширование на клиенте. Там уже люди очень серьезно подумали на проблемами которые вы озвучили (и другими тоже) и много чего хорошего придумали - грех не воспользоватся. Если не самими технологиями то подходами и решениями.

Верните версию как было.

Раз у вас вообще нет никаких требований - то возьмите что-нибудь веселое, Fortran какой-нибудь, или хотя бы Erlang.

Для начала проверьте срабатывает ли эффект при удалении.

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

Если у вас проблема только в том что импорты визуально мешают и лень скроллить то используйте фолдинг:


При использовании нормально навигации по коду вы на начало файлов вообще редко будете попадать.

Я считаю, что первое, что мы хотим увидеть при открытии компонента, - это метод рендеринга.

Считать можно что угодно, у других людей может быть другое мнение. Если вы работаете один - можете делать как хотите, в команде такие вещи надо как минимум обсуждать.

И зачем при выполнении setState() делать копию массива users,

Можете и не делать, если как-то еще дадите реакту знать что стейт поменялся и надо вызывать render.

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

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

Ваш подход лучше если:
1) ваша нагрузка на самом деле превышает то что можно выжать из ангуляра, сделав все грамотно (бандлы, ssr, кеширование, оптимизация зависимостей и так далее)
2) ваша фронтенд команда достаточно покачана чтобы пилить сложный проект на ванильном JS и выжимать из него больше чем можно выжать из фреймворка (это очень непросто)

Что можно сделать:
- определить реальные проблемы
- определить критерии их решения (скорость, размер, page speed и так далее)
- определить время за которое команда готова оптимизировать ангулярное приложение до нужных параметров

Если не сделают - поднять вопрос еще раз, показав свой вариант.

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

Плюс велика вероятность что ваши девелоперы хотят "модно-молодежно" на "современных технологиях" это уже человеческий фактор и он будет самым проблемным.

размонтировать его, перерендерив родительский компонент без Login.

в корневом package.json:
"build": "cd client; yarn build; cd .."

Правильный ответ я уже дал тут: Если props отсутствует Нужно ли использовать memo?