Este é um problema de otimização
Um bom engenheiro entende que um problema de otimização não tem sentido sem um alvo. Você não pode simplesmente otimizar, você tem que otimizar para algo. Por exemplo, suas opções de compilador incluem otimizar a velocidade e otimizar o tamanho do código; estas são, por vezes, objetivos opostos.
Eu gosto de dizer à minha esposa que minha mesa está otimizada para adicionar. É apenas uma pilha e é muito fácil adicionar coisas. Minha esposa preferiria se eu otimizasse a recuperação, ou seja, organizei minhas coisas um pouco para poder encontrar coisas. Isso dificulta, é claro, adicionar.
O software é o mesmo. Você pode certamente otimizar a criação de produtos - gerar uma tonelada de código monolítico o mais rápido possível, sem se preocupar em organizar isto. Como você já percebeu, isso pode ser muito, muito rápido. A alternativa é otimizar a manutenção - tornar a criação mais difícil, mas tornar as modificações mais fáceis ou menos arriscadas. Esse é o propósito do código estruturado.
Eu sugeriria que um produto de software bem-sucedido seria criado apenas uma vez, mas modificado muitas e muitas vezes. Engenheiros experientes viram as bases de código não estruturadas adquirirem vida própria e se tornarem produtos, crescendo em tamanho e complexidade, até que até mesmo pequenas mudanças são muito difíceis de fazer sem introduzir riscos enormes. Se o código foi estruturado, o risco pode ser contido. É por isso que vamos a todo esse problema.
A complexidade vem das relações, não dos elementos
Eu percebo em sua análise que você está olhando para quantidades - quantidade de código, número de classes, etc. Embora sejam interessantes, o impacto real vem das relações entre os elementos, que explodem combinatoriamente. Por exemplo, se você tem 10 funções e nenhuma idéia de que depende, com quais 90 relações possíveis (dependências) você precisa se preocupar - cada uma das dez funções pode depender de qualquer uma das outras nove funções, e 9 x 10 = 90. Você pode não ter idéia de quais funções modificam quais variáveis ou como os dados são passados, então os codificadores têm uma tonelada de coisas para se preocupar quando resolvem qualquer problema em particular. Em contraste, se você tem 30 classes, mas elas são organizadas de forma inteligente, elas podem ter apenas 29 relações, por exemplo, se eles estiverem em camadas ou dispostos em uma pilha.
Como isso afeta o rendimento de sua equipe? Bem, há menos dependências, o problema é muito mais tratável; os codificadores não têm que manipular um zilhão de coisas em suas cabeças sempre que fizerem uma mudança. Portanto, minimizar as dependências pode ser um grande impulso para sua capacidade de raciocinar sobre um problema com competência. É por isso que dividimos as coisas em classes ou módulos, e as variáveis de escopo tão bem quanto possível, e usamos SOLID princípios.