MVC - Visão e Controlador Unificados

A primeira questão é simples.
Suponha que você tem uma empresa e o sistema de controle dos funcionários foi construído seguindo o pattern MVC.
O projeto foi desenvolvido com a camada view em swing.
Agora, como tua empresa cresceu, é preciso manter duas filiais fora do estado e, então, o programa agora terá de ser migrado para web, com JSP/Servlet (exemplo esdrúxulo).
Como as camadas estão bem definidas, basta criar a camada web (view) da coisa. Toda a parte de controle e persistência permanece inalterada.

Agora, quando você mistura as camadas, como sugerido na segunda afirmativa, precisará recompor partes de lógica que ficam perdidas na camada de apresentação. Como fará isso? Qual o custo do trabalho (e retrabalhos posteriores)?

Claro, há paradigmas e necessidades. Também já fui um ferrenho crítico do MVC, hoje vejo, como diria meu gerente de projetos, com bons olhos essa questão. Preciso mudar a lógica, mas a tela não. Preciso trocar de Hibernate para TopLink, mas mantenho a lógica. Preciso trocar de web para desktop, mas não altero mais nada.

Simples. Trabalhoso, complicado de se fazer? Quem sabe, tudo é uma questão de costume (tem gente que prefere trabalhar com grafos de listas duplamente encadeadas em C ou assembler a programar java).

É mais prático manter visão e controlador juntos. Tudo bem aí. Mas não descaracteriza o MVC fazendo isso?

É mais prático para quem tem preguiça.
Mais trabalhoso para dar manutenção.

E ao meu ver, sim, descaracteriza o MVC.

Sim, descaracteriza.

Uma camada de controle se justifica mais nos casos em que a View e o Model estão fisicamente separados, como é o caso da web. Para sistemas desktop, geralmente usar o MVC completo é adicionar muita burocracia, sem um ganho em manutenção que valha o esforço.

Vale lembrar que em sistemas desktop:

a) É impossível o usuário “navegar” para um form inválido;

b) É impossível o usuário inserir parâmetros inválidos de entrada (a view garante 100% de precisão na validação dos dados, desde que não hajam erros de programação). O usuário não pode simplesmente pressionar esc e “desabilitar javascripts” ou simplesmente passar parâmetros “no post”;

c) É fácil comunicar-se entre as camadas do sistema. É simplesmente uma chamada de evento, sem rede, sem sniffers ou intermediários no meio.

Além disso, sistemas desktop tem interface mais rica. Aumenta muito o código se o controlador estiver totalmente isolado, para um benefício um tanto questionável. É por isso que a própria Oracle sugere um modelo MVC simplificado, com Model e Controle juntos, e classes de controle apenas onde for desejável (TableModel, ListModel, etc), e adotou essa decisão no Swing: http://java.sun.com/products/jfc/tsc/articles/architecture/

Em um sistema web, não tem cabimento não fazer a separação das três camadas.