Стоит ли использовать изоморфное приложение в высоконагруженном e-commerce проекте?

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

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

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

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

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

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

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

Пишу backend на Go. Первым делом проектируется API и структуры данных. Фронтендеры говорят мне на каком URI они хотят получить какой JSON и моя задача предоставить это быстро и надежно. Как они собираются этот JSON рендерить мне вобщем то и неособо интересно.

не надо клиента грузить тоннами JS

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

Все мои аргументы, в том числе, что JS априори медленнее Go и не поддерживает многопоточность, нет нормального ООП, и что не надо клиента грузить тоннами JS ради full AJAX, и вообще разработку станет вести легче и быстрее они оспаривают.

В общем случае скорость языка в вебе не критична.
Полно высоконагруженных проектов на медленных языках.

Ибо основные задержки не зависят от языка - это сеть и СУБД (и пр. связанные с дисками операции).

Впрочем, при нагрузке сервера очень большим числом клиентов и/или при очень сложной логике обработки (но не связанной с СУБД/дисками, а завязанной только на процессор) - скорость языка значение уже имеет.

У вас - как? В чем именно узкое место?

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

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

и что не надо клиента грузить тоннами JS ради full AJAX

При несложной логике - да.
При сложной логике - не все так очевидно.

Не насилуйте сервер клиентским кодом!
Отрисуйте все на сервере. закешируйте и отдавайте клиенту.
Дальше используйте фронт для подгрузки данных.
Какие плюсы:
1. 1 коннект к базе данных.
2. 1 статичный файл, который упадет в кэш.
3. 1 статичный файл проиндексируется поисковиками.
4. 1 раз проверяется токен, а не на каждый чих фронтэнда

Изоморфность дает буст только в случаях обычных crud+практически полного совпадения сущностей с бэка и фронта. Это годится для сатиков по заказу пиццы, или записи на стрижку. Но не для чегото среднего/крупного.

Рендерить страницы на Go, как мне кажется, не самая лучшая идея. Плюс зачем вам делать работу, которая, как я понял, не попадает в вашу зону ответственности? Ибо разбираться в этом и пользоваться не вам же, а фронтендщикам (у которых очень популярный фреймворк еле работает).
Если это аналог ozon.ru, то можно и подсмотреть стак у самого озона? Пишите бэкенд на Go, а фронт пусть фронтендщики пишут на связке Node.js + Nuxt.js + Vue.js, тогда вам и быстрый бэкенд, и возможность доступного рендера на стороне сервера, и изоморфность, и человеческий js-фреймворк для фронта.
P.S. Ну Angular реально дичь же.