Це власне дуже добрий приклад хорошого контенту для архітекторів, а не DevOps. Що там «девопсного»? Сценарії для формулювання quality attributes, які вони не роблять, або тактики для їх адресування?
Стилі і дезайн також до девопсів нічого не має.

На мій погляд, я не бачу ніяких причин, чому люди не мають її читати, якщо вона добре написана, та ШІ як інструмент зекономив час, який може бути витрачений на інші активності.
Один із головних моментів мати документацію — це донести інформацію до зацікавлених сторін (стекхолдерів). Якщо вона задовільняє цьому, дає результат і не викликає питать — це вже успішний приклад.
А якщо питання про те, чому люди в принципі повинні читати документацію — то це вже інше)

На мій погляд це не буде змагання, а комбінована команда з взаємодоповненням

Вітаю
В даному випадку мова йде про визначення альтернативних або додаткових планів по процесу, оцінювання показників ефективності, потенційних ризиків, допомога по створенню WBS і так далі. Тут важливий фактор — це створення дієвих інструкцій для генеративної моделі з чіткими показниками і прикладами того, що ми хочемо отримати.

Стосовно безпосереднього оцінювання — так, це цілком можливо, більш того, ми це використовуємо також, наприклад для code review, оцінювання складності та релевантності рішення, допомога в discovery. А також можна піти далі для отримання практичного результату «вертикальний рівень», наприклад, для створення і оцінки плану імплементації задачі, автоматичний фікс code smells з sonar або за висновками на основі генеративної моделі та інше.