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

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

Bazel не связан с монорепозиторием, он может работать с несколькими репозиториями.

С монорепой можно менять/deprecate'ить API библиотеки и сразу же рефакторить использующий ее клиентский код в других проектах монорепозитория. В случае отдельных репозиториев на Gitlab можно настроить триггеры для запуска CI процессов на downstream проектах и отслеживать несовместимые изменения.

А можно вопрос зачем именно монореп, и почему такое решение?

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

Хм. У меня уже многие годы монорепа, но при этом все сервисы деплоятся независимо. В чем проблема?

Ну, из IDE проще работать с одним репозитарием (обычно). Можно выкрутится, но в среднем легче.
Ну и следить за историей фич по одной репе попроще.
Для выкладки, тестирования и т.п. - разницы нет, конечно.

Так системы управления зависимостями нужны в любом случае, что монорепа, что не моно.
Мне удобно, что в монорепа проще поддерживается в IDE, можно делать глобальные поиск и замены, фичи изолированы в одном бранче в одном репозитарии (и не нужно думать о синхронизации состояния бранчей по разным репозитариям), проще делать CI/CD системами типа gradle.

+

В поддержке версий. Как вы решаете историю на уровне git с тем, что у вас один сервис имеет версию 1.2.3, а другой - 4.5.6?

А зачем нужно раздельное версионирование сервисов? И, если уж на то пошло - зачем их вообще версионировать?

вопрос хорош. Не знаю, делал по привычке. Возможно, когда одна prod площадка, то и не нужно.

одна prod площадка и быстрая доставка изменений на prod.

Чем именно проще? Что то, что это - в результате тупо древовидная структура директориев на диске, причём, при желании, идентичная

Я уже давно написал небольшой скриптик, который тупо клонирует на диск содержимое всего гитлаба, со всей гитлабовской  встроенной иерархией, ибо даже как-то лень индивидуально с каждым "проектом" разбираться.
И SourceTree и VS Code прекрасно импортируют рекурсивно все репы от общего корня.
Чем это отличается от монорепы, кроме того, что общий корень ничем не захламлён, а за каждым потоком коммитов можно следить избирательно - не знаю

Версионирование сервисов нужно, если они выставляются в качестве api наружу. Как правило, чтобы не ломать клиентов, одновременно поддерживаются несколько версий api, потом со временем старые версии убираются

гугл в честь пятилетия кубернетес сделал курс по нему бесплатным. Если вы хотели, но что-то мешало, то вот — https://inthecloud.withgoogle.com/kubernetes-training-offer/register.html

Монорепа не проще поддерживается в ide. Как только репа разрастается, чтобы вам просто поработать с каким-то кодом, надо будет выключать анализаторы в ide и/или выкачивать лишние данные в большом количестве от левых зависимостей

Ну и я молчу про то, сколько места будет это все занимать...

До такого масштаба не все доходят. Ну и монорепа - это не обязательно один репозиторий на всю компанию. Основная идея - не плодить репозитории без особой необходимости.