> Начнём с того, что вложенные структуры конкретно данную проблему не исправят, а
> только добавят скобочек в визуально случайных местах инициализации структуры.

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

> Продолжим тем, что глупо добавлять структуры только для того, чтобы уменьшить число
> полей в каждой из них. Это вам не Ява, где шаг
> вправо-шаг влево - и у вас сонаркуб заругается,

Ну так правильно заругается. Нефиг гамнокодить. Структуры с дохреналионом полей уж точно не признак мастерства архитекта и изящества архитектуры.

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

Со своей стороны я буду считать что более ~десятка полей в структуре - "кодер был неадекватен и делал какую-то фигню или не смог в архитектуру, гамнякая в режиме питоняши".

> И закончим на соседней новости, где просто изменением порядка полей в большой
> структуре добились увеличения производительности на 40%.

А вот там господа таки - понимают что делают - и структур  с более 9000 полей не заводят. И вложенные структуры юзать не гнушаются. Такая ерунда.

> В случае со вложенными структурами эта оптимизация была бы где-то в диапазоне
> от "выглядит бредово" до "это невозможно".

С чего бы это вдруг? А 1 из примеров - заменили struct на u32. Стало даже проще. На самом деле есть tradeoff между нуждами оптимизации кода и изящностью и логической консистентностью апи. Не всегдя изящное логичное апи хорошо маппится на конкрерику оптимизера вот тут. Тот кто не джун и уже умеет в архитектуру и управление проектом немного - понимает что нужен какой-то разумный баланс. Если у вас более 9000 полей в структуре, очевидно, это профачено.