Почему такой выбор?
1. Потому что парой строк в Ignition можно включить автоапдейты в определенные часы¹, которые на относительно дохлом железе (главное чтобы io было хоть немного лучше старого 5400 hdd) сами применяются за пару минут и точно ничего не ломают. Из-за next и testing каналов (и небольшой задержки в stable), на CoreOS ещё тяжелее поймать проблемный апдейт, а в случае чего — откат делается одной командой или выбором другого пункта загрузки в grub. Ждём когда доделают автооткаты кривых обнов на основе дистрибутивных и собственных правил — тогда вообще сказка будет.
2. Ignition (можно ещё Ansible, если на сервере много чего раскатывать надо) даёт возможность вообще не переживать на тему состояния, разметки дисков и конфигов сервера, т.к. при желании сервер перенакатывается (или накатываются аналогичные параллельно) со всем нужным барахлом левой пяткой. Более причёсаный вариант федориных кикстартов, но на самом деле и кикстарты мощная вещь.
3. (Пункт в целом про федору/RHEL) Из коробки нормально работающие podman с пользовательскими контейнерами, unified cgroups v2 (первые cgroups ЕМНИП даже их создателю не нравились) и прочее удобное барахло. На большинстве дистров это до сих пор не дефолт или стало им совсем недавно, как на убунте. А на шляпах подобные вещи появляются в самый подходящий момент — когда технология уже показывает себя хорошо, но не с задержкой в 3-5 лет, когда это уже давно внедрено у конкурентов :/
4. Эта система создавалась для OpenShift кластеров, но по факту интересна и без них. Контейнеры часто запускаются без таких монстров (особенно на подкроватных локалхостах или IoT), а удобная ОС чтобы их гонять всё ещё нужна. И когда у тебя весь софт в контейнерах, то не сложно воспользоваться преимуществами иммутабельных систем, вроде простоты обслуживания и предсказуемости. Если нужное ПО всё ещё крутится не в контейнерах, то иммутабельная ОС тут будет побоку, потому что в данном случае есть проблемы поважнее.
5. Собственные образы CoreOS очень легко собираются либо через Image Builder (SaaS на console.redhat.com или self-hosted), либо через Containerfile. Это может быть предпочтительнее, чем леерить кучу ПО в стоковый образ, но это уже от конкретной ситуации зависит.
^1: Если нужна высокая доступность сервисов, то либо у вас уже okd/openshift на нескольких машинах с той же CoreOS под капотом, либо что-то аналогичное. В остальных случаях есть окна обслуживания, в которые спокойно можно обновляться.