1. Думаю что разработчики любой системы считают себя хорошими. Было бы странно, если разработчик скажет, что да, система плохая, кривая и ничего сделать не можем. В таком случае систему проще похоронить, чем заставлять страдать и себя и пользователей.
1.1. Партнеры бывают разные. По своему опыту знаю, партнеры написали какой-нибудь отчет, пользователи начали им пользоваться и резко возросла нагрузка на базу и отчет строится крайне долго. В результате приходится оптимизировать, либо переписывать, либо оставлять как есть. Если оставим как есть, то пользователи будут страдать. Плюс они не знают кто конкретно это делал и считают, что это разработчики плохие.
2. Задачи создаются на основе обращений в техподдержку. Если обращаются по поводу какой-то ошибки, то воспроизводим ошибку и создаем задачу на исправление. Если речь идет об интерфейсе, то часто бывает, что это не ошибка. Просто пользователь забыл что-то заполнить. В этом случае ему объясняется почему система реагирует так, а не иначе. Соответственно кидаться что-то исправлять на основе каких-то "хотелок" по меньшей мере странно. Такое реагирование на обращения в техподдержку используется везде, а не только у нас.
П.С. Когда-то давно лично я не писал. Возможно кто-то другой был.

То есть микросервисная архитектура и объединение сервисов *(лучших сервисов, практик, компетенций) не рассматривается. Только одно решение ?

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

Я вот другого мнения, расскажите за технические нюансы.

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

Я вот другого мнения, расскажите за технические нюансы.

Главная проблема в разделении данных. По каким критериям делить? Как потом агрегировать данные?

С этим вообще проблем нет, от слова совсем.

Да ну? То есть например выделяем стационар и поликлинику в отдельные сервисы. Делаем им отдельные базы. Следовательно условный справочник пациентов у нас будет в обеих базах. И таких дублирующихся справочников будет много. Но в принципе тоже не проблема. А вот если врач из стационара захочет открыть ЭМК пациента и посмотреть с какими заболеваниями он обращался в поликлинику. Данные откуда тащить будем?
А потом возникает необходимость собрать отчет, чтоб в него попадали данные и из стационара и из поликлиники. Будем делать общую базу? Ну допустим. Вопрос, что это даст кроме увеличения затрат на оборудование?

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

Ок. База одна, тогда в чем смысл микросервисной архитектуры для пользователей? Какая им разница монолит там или микросервисы? Пользователям нужно чтоб всё работало и работало быстро. В данном случае скорость упирается в скорость базы. Именно для этого и пилят монолиты на кусочки, так как одна база не справится с нагрузками.

Было сказано , это проблемы миац , отвечает миац за рмиас , не поминацте об этом всуе

Не только БД может быть проблемой и узким местом.. Что касается конкретно пользователя - да, ему вообще без разницы. Но к примеру вносить изменения в монолитное приложение или в его часть снижает риски, издержки. У всего есть конечно свои плюсы и минусы, микросервисы в основном любят за ряд плюсов селективное горизонтальное масштабирование, можно еще и упомянуть про MSA  / SOA.

Итого, Мы же можем масштабировать фронт, бек, есть же разные инструменты. В Москве вот не поскупились от слова совсем *(например подняли зеркало БД только на чтение, и строят на ней в живую все отчёты) у Вас же в Промеде внёс изменения и сиди гадай 10-40 минут пока данные обновятся, что до узких мест что в монолите, что на микросервисной архитектуре это решается довольно просто, было бы желание - это первое, второе наверное компетенция и не только.

В у Промеда нет проблем с производительностью фронтенда/бекенда. Для этого делить на микросервисы не нужно. В плане большей "модульности" в принципе возможно что-то поделить. Но всё упирается в БД. А что касается "поднятия дополнительной БД", мы всеми руками за, только железо же не наше, а регионов. Мы можем только рекомендовать, а если регион скажет, что у них нет средств на дополнительные мощности, то этих мощностей и не будет.
По поводу 10-40 минут ожидания обновления данных, хочется уточнить, про что идет речь?

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

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