Primeiro de tudo, eu amo essa pergunta. Eu escrevi como três respostas de 1000 palavras e elas estavam terrivelmente erradas quando cheguei ao fim delas.
O problema em tentar comparar os dois como análogos, eu acho, é que a programação é um processo de modelagem que pode ser tão abstrato ou strongmente ligado ao concreto como você quer.
A teoria da engenharia estrutural, por outro lado, está strongmente vinculada a conjuntos muito específicos de leis baseadas na realidade às quais você deve obedecer. Você não pode simplesmente alterar o contexto ou as leis. O problema em si está enraizado nessas leis. Na programação, no entanto, às vezes a solução está realmente alterando a natureza da questão ou simplesmente colocando-a em um contexto diferente.
Se o padrão MVC, por exemplo, é um ajuste perfeito, tem muito a ver com esse contexto. Normalmente, um aplicativo de desktop lida apenas em um idioma e em um idioma, sem contar os arquivos de configuração.
O front-end de um aplicativo da web, por outro lado, consiste principalmente em dois idiomas declarativos (não-programação) e JavaScript. A única coisa física que você não pode abstrair completamente é o fato de que há sempre essa parede http para chuck as coisas entre o servidor e o navegador. Independentemente de como você o enterra no código, isso leva tempo e um design assíncrono.
Obviamente, você não pode usar um padrão popular e bem conceituado como o MVC para lidar com as preocupações do front-end na Web exclusivamente, sem alterar a maneira como você pode lidar com isso em um contexto de aplicativo de desktop. Na verdade, eu diria, você deve estar ciente do que torna o MVC útil, mas nem mesmo tentar implementá-lo de maneira particularmente exigente ou por atacado. O paradigma do aplicativo da web é único, pois todo o material "look-at-me" é manipulado pelo navegador do usuário e todos os dados / modelo-ish são tipicamente no servidor em algum lugar. Mas onde isso deixa o controlador? Tudo no servidor ou tudo no front end? Alguém tem que possuir isso. Ou talvez o MVC não seja 100% o melhor ajuste para o cenário. Não é um ajuste ruim para o material de back-end do .NET. Não é terrível no contexto de widgets da interface do usuário específicos. Mas tentar aplicá-lo a tudo por uma questão de consistência pode ser uma má jogada, IMO.
Construir uma casa resolve um problema. Problemas típicos de programação, no entanto, geralmente envolvem a solução de problemas dentro de problemas e, às vezes, a solução é redefinir o problema externo. A realidade não está especialmente interessada nessa ideia, infelizmente.