Понятнок дело, что выхлоп деятельности должен быть оцене положительно

И с чего бы это новые команды будут заниматься тем же?

У команд могут быть немножко разные задачи и домены.

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

А вот как раз это пример в мою пользу
США давно хотели присоединиться к СИ, трагические события помешали это сделать, а теперь поменять систему очень дорого

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

Потом появились команды А1 и Б1 как усиление А и Б.

Потом появятся А2 и Б2 и Б3.

Общего глоссария так и не будет, но всё работает.

Вполне разумно оставить всё как есть в такой ситуации. Она не совпадает с моим примером, а как я говорил, у такой деятельности должна быть оценка, выдающая в прогнозе хорошую экономию. Потому что если прогноз говорит "на 2% эффективнее станем", очевидно что всю пользу съедят неучтенные факторы-помехи

Поехали дальше.

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

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

Та-да-да-дам. Второй звонок.

Что в мобильный клиент, что в отчёты залетают новые фичи. Скажем, в мобильный клиент залетает своя интеграция со стандартом Mobile Device Management.
В отчёты залетает Tableau.
В платежи залетает какой-то Bluefin.
В команду интеграций залетает такое что без специальных платных тренингов вообще не разберёшься как работает.

Если вы хотите чтобы КАЖДАЯ команда владела словарём КАЖДОЙ другой, вам надо потратить в пять раз больше времени, чтобы КАЖДЫЙ программист и тестировщик в другой команде получил ту же информацию. Кроме того они гарантированно забудут её без практики (а практики у них нет, потому что они на своих задачах), и через пол-года у тебя будут спрашивать опять "а что такое это MDM?"

Если вы хотите чтобы владела не только словарём, но и практикой по фичам, вам надо потратить ещё больше времени.

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

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

Пример наоборот. Покупаем 1 или даже 3 команды целиком из очередного развалившегося гигантв типа рамблера.

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

> Тогда теряется взаимозаменяемость людей, вплоть до того что в команде пилит каждый свой кусок и про других ничего знать не знает.

Не теряется. Её не было, нет и не будет, как не заменишь фронтендера на джаваскрипте айосником или пхпшником.

Пример - общие компоненты фронтенда для разных проектов

Если они были. Или есть. Или будут. В админке кастомные, в отчётах Tableau . Общего аж база данных.

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

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

>  можем получить проблемы интеграции, а то и ситуацию когда весь анклав проще уволить

Разумеется можем получить. Но можем получить и по куче других причин, вроде, как я уже указал "неинтересно" или "несовместимость" и пр.

В этом плане я таки сторонник аналога lazy initialization — заводите введение в понятия тогда когда оно вам реально понадобится или вот-вот понадобится. Потому что если заведёте его сильно заранее без практики, всё забудется под потоком текучки.

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

Может, не обязательно сэкономит

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

Советую забыть про универсальные правила для всех независимо от количества человек.
Потому что и общего кода может не быть, и общих компонент, и общего глоссария.
Могут быть команды / проекты без UI , которым дизайн система нужна как абстрактному пожарному абстрактный курс по парусному спорту.  
И с knowlege transfer могут быть проблемы просто если не налажено.

с такими компонентами кстати даже тестировать лучше - любой тестер с любого  продукта знает ожидаемое поведение UI элементов