Excelente ponto, e você matou a charada quando falou do mix de trabalho!
Os meus 80% vêm da minha rotina prática de desenvolvimento de software (é uma estimativa empírica do meu fluxo diário, e não um benchmark paralelo controlado como o seu teste).
No desenvolvimento de código, a maioria esmagadora das tarefas é muito atômica e delimitada: escrever um teste unitário, ajustar um schema de banco, alterar um endpoint ou refatorar uma função isolada. Como o escopo do arquivo é pequeno e a própria suíte de testes valida o resultado na hora, os modelos menores resolvem a maior parte do dia a dia sem engasgar. Eu só escalo pro modelo pesado quando a tarefa envolve concorrência, segurança, investigação de bug de causa desconhecida ou decisão de arquitetura.
Mas pro seu caso de escrita técnica longa, concordo 100% com a sua observação. Manter a mesma voz, coesão e linha de raciocínio ao longo de um texto extenso é onde os modelos menores mais pecam (essa descrição de "parecer escrito por quatro pessoas diferentes" foi perfeita).
E achei excelente o seu eixo de "rigidez de formato": se o objetivo é alimentar uma pipeline com dados estruturados, o modelo menor ganha de lavada porque ele não tem a tentação de "ser criativo" e colocar notas adicionais onde só se pedia um schema seco.