Todos os princípios são válidos, mas no meu entendimento, eles não se aplicam a · eliaseas

Todos os princípios são válidos, mas no meu entendimento, eles não se aplicam a todos os projetos.

Por exemplo, eu preciso perder tempo otimizando algo para encaixar num requisito de hardware, se esse projeto tem um orçamento alto, ou se é um projeto tão pequeno que mesmo mal otimizado ele irá funcionar bem até num raspberry pi?

"O verdadeiro mestre é o passado":
grandes empresas como bancos por exemplo vivem no passado, pela segurança, pela confiabilidade. Pra eles o que importa é que funcione bem, "foda-se" se o programador vai ter que aprender a programar em Cobol, viver numa codigo cheio de retalhos e ter uma pessima devx.

Você ta fazendo um código novo, quer que ele seja bonito, legível, moderno.

Enfim, acho que em varios pontos de aplica o bom e velho DEPENDE.

Eliaseas, você está absolutamente correto. Esses princípios foram pensados tendo em mente projetos muito específicos, cujo objetivo é escrever um código livre de bugs, que possa se provar que o software faz exatamente o que deveria fazer e nada além disso. O título, ao contrário do que foi sugerido por Wymored, não é apelativo, mas sim direto ao ponto. Veja que não mencionei otimização especificamente, o uso máximo de recursos pode ser quão generoso seja apropriado, desde que seja conhecido e controlado.

Quando você está desenvolvendo um código novo, naturalmente deseja que seja bonito e legível. Concordo plenamente com isso. No entanto, a questão de ser "moderno" é onde devemos ter muita cautela. Não existe uma qualidade intrínseca em ser moderno; muito pelo contrário, ser moderno implica ser novidade, ser pouco testado, ser instável, enfim... Veja o Next.js, considerado uma das das ferramentas "modernas" para desenvolver aplicações web: mais de 2000 issues abertas no GitHub. Isso mostra que novidade é praticamente sinônimo de bugs.