KYAML vs YAML: зачем усложнять простое?

YAML давно стал привычным инструментом для DevOps. Но у него есть обратная сторона: неявные типы, зависимость структуры от отступов и множество возможностей, которые Kubernetes на самом деле не использует.

Kubernetes предлагает более строгий подход к конфигурациям — KYAML и описывает его преймущества в своем блоге. Идея в том, чтобы оставить от YAML только то, что действительно нужно Kubernetes, и убрать неоднозначности.

Что получает DevOps?
🟡 меньше зависимости от отступов;
🟡 более предсказуемую работу со строками и типами;
🟡 явное обозначение списков [] и структур {};
🟡 более удобную работу с генерацией, шаблонами и автоматизацией;
🟡 KYAML остаётся валидным YAML и рассчитан на совместимость с существующими YAML-парсерами.

Но есть и другая сторона. Среди обсуждений инженеров можно встретить мнение, что KYAML не избавляет Kubernetes-конфиги от сложности, объясняя это тем, что: 
🟡 KYAML не уберёт Helm-шаблоны, огромные манифесты и десятки взаимосвязанных параметров. А значит, вместо решения основной проблемы можно получить ещё один формат, который команде придётся изучать и поддерживать;
🟡YAML уже встроен практически во всю DevOps-экосистему — от IDE и линтеров до CI/CD-инструментов. KYAML — новый подход, а значит, не все инструменты одинаково хорошо его поддерживают.

И здесь возникает главный вопрос:
KYAML действительно решает проблемы YAML — или просто вводит более строгие правила там, где и так всё работало?

👀 А вы бы использовали KYAML в своих проектах, либо же обычного YAML вам вполне хватает? Поделитесь мыслями.