Eu mesma lutei com isso. Há casos em que faz sentido usar um DTO na apresentação. Digamos que eu queira mostrar uma lista suspensa de empresas em meu sistema e preciso de sua id para vincular o valor.
Bem, em vez de carregar um CompanyObject que pode ter referências a assinaturas ou quem sabe o que mais, eu poderia enviar de volta um DTO com o nome e id. Este é um bom uso IMHO.
Agora veja outro exemplo. Eu tenho um objeto que representa uma estimativa, esta estimativa pode ser composta de mão de obra, equipamento etc, pode ter muitos cálculos que são definidos pelo usuário que pegam todos esses itens e os somam (cada estimativa pode ser diferente com diferentes tipos de cálculos). Por que eu deveria modelar este objeto duas vezes? Por que não posso simplesmente fazer com que minha IU faça uma enumeração dos cálculos e os exiba?
Eu geralmente não uso DTOs para isolar minha camada de domínio de minha IU. Eu os uso para isolar minha camada de domínio de um limite que está fora do meu controle. A ideia de que alguém colocaria informações de navegação em seu objeto de negócio é ridícula, não contamine seu objeto de negócio.
A ideia de que alguém colocaria validação em seu objeto de negócio? Bem, eu digo que isso é uma coisa boa. Sua IU não deve ter a responsabilidade exclusiva de validar seus objetos de negócios. Sua camada de negócios DEVE fazer sua própria validação.
Por que você colocaria o código de geração de IU em um objeto busienss? No meu caso, tenho objetos separados que geram o código da IU separadamente da IU. Eu tenho vários objetos que renderizam meus objetos de negócios em Xml, a ideia de que você tem que separar suas camadas para evitar esse tipo de contaminação é tão estranha para mim porque por que você colocaria o código de geração de HTML em um objeto de negócios ...
Editar
Como penso um pouco mais, há casos em que as informações da IU podem pertencer à camada de domínio. E isso pode obscurecer o que você chama de camada de domínio, mas trabalhei em um aplicativo multilocatário, que tinha um comportamento muito diferente tanto na aparência da IU quanto no fluxo de trabalho funcional. Dependendo de vários fatores. Nesse caso, tínhamos um modelo de domínio que representava os locatários e sua configuração. Sua configuração passou a incluir informações da IU (rótulos para campos genéricos, por exemplo).
Se eu tivesse que projetar meus objetos para torná-los persistentes, também deveria ter que duplicar os objetos? Lembre-se de que se deseja adicionar um novo campo, agora você tem dois locais para adicioná-lo. Talvez isso levante outra questão se você usar DDD, todas as entidades persistentes são objetos de domínio? Eu sei que no meu exemplo eles eram.