Há muitas respostas aqui que abordam os prós e contras técnicos de manter o LOC baixo e se é ou não uma métrica de software de qualidade significativa. Não é sobre isso que esta questão é. O que é sobre como lidar com a administração que insiste em uma aderência dogmática ingênua a uma regra de codificação específica.
Infelizmente, é bastante comum que as pessoas se envolvam em coisas que são bons conselhos quando usadas no contexto apropriado e aplicadas de forma pragmática, tirando-as desse contexto e aplicando-as dogmaticamente, sem avaliar os problemas que o conselho existe para mitigar o primeiro lugar.
A intenção de conselhos sobre manter o LOC down é evitar a criação de métodos que tentem fazer muito de uma só vez, e desencorajar a criação de "classes de deus", que sabem muito sobre aspectos de um design que não são sua responsabilidade direta e da qual todas as outras classes do sistema dependem. Outra vantagem do código mais curto é que ele é mais legível, embora, como você apontou, você possa exagerar até o ponto em que a legibilidade realmente começa a sofrer.
Existem vantagens óbvias para contagens baixas de LOC (pequenos métodos se encaixam em sua cabeça mais facilmente do que os grandes, menos coisas no código significam menos coisas para dar errado, etc.), mas também estão sujeitos à lei de retornos decrescentes. . Refatorar um método de 150 linhas em um número de 20 métodos de linha é uma vitória muito maior do que refatorar um método de 10 linhas em um método de 7 linhas.
Quando essa refatoração ocorre às custas de alguma outra faceta do bom design de software (como legibilidade), você chegou a um ponto em que pode justificar que você não o faça. Remover variáveis que contextualizam o significado do código e substituí-las por literais que não o fazem é algo muito ruim de se fazer. Um bom código quase não possui literais. No entanto, essas variáveis (e constantes nomeadas) são linhas de código que não contribuem diretamente para o programa e, portanto, se LOC estiver sendo adorado como algum tipo de deus, tais linhas de esclarecimento estarão em grande risco de serem eliminadas para uma rápida vitória. alguns elogios equivocados da administração.
Eu acredito que você é inteligente o suficiente para perceber isso, na verdade, é basicamente o impulso da sua pergunta original. O problema não é sua compreensão de quando a redução do código é boa e quando não é, o problema é o dogmatismo em aplicar o que normalmente é uma prática razoável indiscriminadamente.
Eu recomendaria reservar um tempo para conversar com sua gerência, explicando sua posição e por que você acha que o que está sendo solicitado a fazer prejudica o código, em vez de ajudá-lo. Tente evitar ser conflituoso, mas tente permanecer racional e calmo durante essa discussão. É importante que sua gerência entenda que a programação é uma atividade pragmática, e o aconselhamento sobre práticas recomendadas só é útil se aplicado de forma pragmática. A melhor prática é escrita em um livro, não gravada em pedra, e quando está em conflito (código curto versus código legível), cabe ao programador aplicar seu julgamento sobre qual melhor prática seguir. Espero que eles sejam pessoas razoáveis que apreciam informações como essa.
Você também precisa ser um pouco corajoso, porque se você está sendo pressionado a reduzir o LOC onde você acha que é desnecessário ou inadequado, então é natural que você faça a mudança de qualquer forma por uma vida tranquila. Você precisa resistir a fazer isso, e você tem que "possuir" essa decisão. Em uma situação em que o gerenciamento é razoável, você não deveria aderir exatamente às suas diretrizes, mas deve ser capaz de justificar quaisquer circunstâncias em que não o faça.
Infelizmente, as pessoas podem ser irracionais, especialmente quando se trata de pessoas que estão na hierarquia questionando suas decisões e as regras que impuseram a você. Eles podem escolher não ser razoáveis. Você precisa estar preparado para isso também. Se você puder demonstrar casos em que a prática recomendada de LOC entra em conflito direto com outras práticas recomendadas e por que isso está prejudicando o produto, e se você pode fazê-lo em partes da base de código para a qual eles tiveram pouco ou nenhum envolvimento pessoal não parece um ataque pessoal ao seu trabalho ou trabalho que eles supervisionaram), então isso pode ajudar a reforçar seu argumento. Novamente, você tem que estar preparado para se justificar de uma maneira calma e racional e ser capaz de "possuir" os argumentos que está fazendo.
Desde que sua gerência seja uma pessoa razoável, eles devem entender que o que você está dizendo tem mérito, se puder fornecer evidências para respaldar suas reivindicações.