Olá Rodrigo,
Realmente é uma questão de abordagem.
Pensando no conceito básico de qualquer objeto, poderíamos sim tirar proveito de tudo que a classe (object model) nos oferece para interagir com o estado do objeto, sendo assim os próprios setters (e até mesmo os construtores) poderiam nos ajudar a restringir a alteração deste estado.
A questão é que talvez todo esse código que tem por objetivo validar dados pode ficar espalhado por diversos setters, aumentando a responsabilidade de cada um deles. A cada alteração de regras de validação talvez teríamos, entre linhas de código para outros fins, encontrar o ponto adequado para realizar a manutenção. Se quisermos testar unitariamente nossa lógica de validação, precisaríamos também aferir todos os comportamentos dos setters do nosso objeto de domínio, esperando ou não por exceptions de validação.
Extrair essas regras de validação para os chamados Validators, facilita essas questões. Temos todo código que representa validação de um modelo, isolado em uma única classe, contendo essa como sua única responsabilidade. A manutenção, evolucão e testabilidade também podem ser favorecidas.
A grosso modo, é como se tivéssemos uma "camada" de validação auxiliando nossa regra. A partir da aplicação da validação nosso objeto de domínio e seus comportamentos podem permanecer bem enxutos e mesmo assim ter a segurança de trabalhar com dados válidos.
Outro ponto que podemos perceber é que utilizando frameworks como por exemplo o Spring MVC, já podemos tirar proveito de toda essa estrutura que já vem pronta, incluindo validação de entrada, apresentação de erros de validação, etc, sem muito esforço.
Enfim, um pouco da minha opinião sobre o caso. Espero ter contribuído.
Abraço
