Incrível guaracy! Muito obrigado pelos links, abriu muito minha mente sobre o assunto. Com certeza visar o valor do produto final antes da tech/arquitetura do código é o melhor pra garantir um projeto simples e eficiente. Mas ainda me parece um tanto vaga a ideia de simplicidade que o Carl tanto defendeu. Ele cita a abstração como um ponto, o que é uma boa prática bem consolidada hoje como ele mesmo disse no artigo de 2001, mas não entendi direito o que quis dizer com o segundo ponto.
Muitas vezes, uma lógica complexa para ser abstrata demanda um código extenso - que poderia ser "simplificado" se aproveitando de recursos da framework ou de uma lib. Até onde podemos dizer que isso é uma boa prática, ou seja, que segue o princípio da simplicidade e não culmina num eventual cenário B do artigo que você referenciou que usa a empresa de carros como exemplo?
Vamos considerar o ponto que o próprio Carl levantou sobre como linguagens como C++ e Java acabam complicando algo que o Rebol faz em uma linha. Se eu implemento como padrão na empresa esgotar todos os recursos das techs que utilizamos em prol de código menos verboso e repetitivo, acabo com códigos complexos que dificultam a manutenção e fazem estagiários e júniores novos serem incapazes de compreender o que lêm. Se eu implemento a desmotivação do uso extensivo de recursos externos à linguagem, acabo com projetos muito maiores do que poderiam ser e que, querendo ou não, não vão se adequar aos padrões do mercado - o que afasta cada vez mais minha empresa dos devs que tenho interesse em contratar.
Essa conversa toda não se resumiria em dois caminhos: complexidade no micro e simplicidade no macro (o que o Carl defendia), ou o inverso (o que parece ser a tendência do mercado)? Não vejo como pode haver simplicidade em ambos sem utilizar dos recursos mais modernos. Afinal, é como eu tinha dito, querendo ou não a internet e o desenvolvimento não são mais os mesmos de 15, 20, 30 anos atrás. As necessidades são outras. Ser de tech significa estar constantemente atualizado. Isso só não precisa significar ser dependente das techs que usa. Acho que é possível sim ser auto suficiente e independente de frameworks sem se tornar um ermitão.