A maior parte do foco aqui parece estar em torno da palavra sempre . Sim, absolutos são ruins, e engenharia de software é quase tanto arte quanto ciência, e tudo isso ... mas eu vou ter que dizer que, para o exemplo que você deu, o método seria melhor se fosse dividido acima. Estes são os argumentos que eu normalmente usaria para justificar a divisão do seu método:
Legibilidade: Não tenho certeza sobre outras pessoas, mas não consigo ler 350 linhas de código rapidamente. Sim, se é o meu código próprio , e eu posso fazer muitas suposições sobre isso, eu poderia examiná-lo rapidamente, mas isso é além do ponto. Considere o quanto esse método seria mais fácil de ler, se ele consistisse em 10 chamadas para outros métodos (cada um com um nome descritivo). Fazendo isso, você introduziu uma camada no código, e o método de alto nível dá um esboço curto e doce para o leitor sobre o que está acontecendo.
Editar - para colocar isso em uma luz diferente, pense nisso é assim: como você explicaria esse método para um novo membro da equipe? Certamente tem alguma estrutura que você pode resumir ao longo das linhas de "bem, começa fazendo A, depois B, depois C, etc". Ter um método curto de "visão geral" chamando outros métodos torna essa estrutura óbvia. É extremamente raro encontrar 350 linhas de código que não beneficiem; o cérebro humano não está destinado a lidar com listas de centenas de itens, nós os agrupamos.
Reutilização: Métodos longos tendem a ter baixa coesão - eles
frequentemente fazem mais de uma coisa. A baixa coesão é inimiga da reutilização; se você combinar várias tarefas em um método, acabará sendo reutilizado em menos lugares do que deveria.
Testabilidade e coesão: mencionei complexidade ciclomática em um comentário acima - é uma bela boa medida de quão complexo é o seu método. Ele representa o limite inferior do número de caminhos únicos através de seu código, dependendo das entradas (edit: corrigido de acordo com o comentário de MichaelT). Isso também significa que, para testar adequadamente seu método, você precisaria ter pelo menos tantos casos de teste quanto o seu número de complexidade ciclomática. Infelizmente, quando você reúne partes de código que não são realmente dependentes umas das outras, não há como ter certeza dessa falta de dependência, e a complexidade tende a se multiplicar. Você pode pensar nesta medida como uma indicação do número de coisas diferentes que você está tentando fazer. Se for muito alto, é hora de dividir e conquistar.
Refatoração e estrutura: Métodos longos são frequentemente sinais de que falta alguma estrutura no código. Muitas vezes, o desenvolvedor não conseguia descobrir quais são os pontos em comum entre as diferentes partes desse método e onde uma linha poderia ser traçada entre eles. Perceber que um método longo é um problema e tentar dividi-lo em métodos menores é o primeiro passo em um caminho mais longo para realmente identificar uma estrutura melhor para a coisa toda. Talvez você precise criar uma classe ou duas; não vai necessariamente ser mais complexo no final!
Eu também acho que neste caso, a desculpa para ter um método longo é "... algumas variáveis declaradas fora do loop principal são alteradas durante o loop". Eu não sou especialista em Python, mas tenho quase certeza de que esse problema pode ser trivialmente corrigido por alguma forma de passar por referência.