Так, а теперь давай поговорим про сервис-провайдера с 10 приложениями, которые предоставляются как сервис на 1500 организаций с переменным количеством пользователей от 2-200.

OU в этом случае выступает в роли хранилища конфигурации теннанта. Что твой пример, что пример ВыньОпуха, который использует OU не по назначению, не учитывает задач, которые держит и обеспечивает AD именно благодаря наличию OU.

Теперь давайте посмотрим на то что может предложить FreeIPA:
1. Установить 1501xN инстансов самой себя, где N - избыточность для отказоустойчивости
2. Переписать приложения так, чтобы авторизация и её разграничение работали относительно группы, и радостно игнорировали все остальные объекты, которые могут получить в рамках иерархии.
Я уже не говорю что в первом случае будет при контроле за Kerberos-доверием, когда речь идёт об объектов управляющего контура.

Люди которые пишут FreeIPA оторваны от реальности. Ориентируются на малый средний бизнес причем без поддержки поглощения одной компании другой. А между тем, некоторым людям нужен именно каталог с корректной структурой иерархии. То, что насовать атрибутов быстрее, чем делать полноценный каталог - это не аргумент.
Вся эта скорость (группы быстрее OU) обусловлена производительностью бекенда. Это 2 разные проблемы:
- техническая (LDAP поверх OLTP медленно работает с OU при поиске)
- гуманитарная (OU с возможностью делегирования необходимы как сущность каталога для внешнего управления авторизацией мультитеннантного приложения)
Наличие одной проблемы не отменяет другие задачи. Собственно именно из-за такого непонимания целей мы имеем засилие AD, которое можно ругать сколько угодно, но оно работает так как надо, а в FreeIPA никак не научится за 10 лет в OU. Видимо, надеются, что крупный провайдерский софт, который хочет OU и предполагает его наличие, предполагает вынос авторизации и собственных расширенных атрибутов в каталог вдруг ломанётся переписывать весь свой софт целиком ради поддержки FreeIPA и её специфических решений, где сами разработчики отказываются ставить в приоритет такую банальную задачу, а оголтелое сообщество кричит "не нужно, медленно" и прочий бред сивой кобылы в лунную ночь.

P.S. Атрибуты которые нужно быстро искать и выдавать не нужно хранить ни в базе, ни в каталоге, так никто не делает. Их выносят на отдельно стоящий кэш-кластер, структура которого специфична для приложения и движка поиска.