Esse é um dos principais conceitos da programação orientada à objetos. O seu objetivo é proteger os dados internos de uma classe aos interesses externos.

A primeira vez que nos deparamos com informações sobre os princípios da OOP, o encapsulamento (geralmente) como conceito, traz a ideia de que tornar atributos privados é a essência da proteção dos dados de uma classe. Dia após dia, os jovens programadores de Java, enchem os seus projetos de classes anêmicas recheadas de anotações (que com o uso de espelhamento) para gerar seus getters/setters por baixo dos panos e distribuem a lógica do negócio para longe do domínio, com a defesa de alguma arquitetura por aí.
O que nem todo mundo sabe é que o sistema pode apresentar muita fragilidade (e inutilidade) com o overengeneering do desacoplamento da validação.

O exemplo do código mostra a implementação de um gerador como o Lombok, ou de uma classe anêmica comum. Como é possível perceber, o modificador de acesso é completamente inútil já que o setter não possui qualquer verificação de entrada. Qualquer valor (desde que do tipo esperado), inserido por meio do método, será aceito e isso pode representar uma falha de segurança, se alguém encontrar um jeito de instanciar essa classe diretamente.
Esperar que colocar as regras de negócio nas bordas da arquitetura vai salvar toda a aplicação, pode representar um erro futuro de proteção à consistência da informação.
Separar as regras de negócio do domínio também representa uma quebra de encapsulamento, já que estamos informando à outras entidades (e fornecendo o acesso) como atribuir valores e com isso, transferimos essa responsabilidade para outras classes, quebrando padrões de design.

Analisando esse código, é possível perceber que continuamos cometendo o mesmo erro de confiar a propriedade da validação à outras classes, mas vamos além: estamos permitindo o acesso de modificação de uma lista para qualquer um que obtê-la.
E não é exagero; ao chamar getContas() recebemos o objeto List e toda possibilidade de ações que a classe implementa. Perigoso não?

E então qual a solução para esses problemas?
Trabalhar com classes anêmicas não é um problema, mas quando utilizamos elas para definir o modelo do nosso negócio, continuamos expondo nossa implementação e nossas regras mesmo utilizando modificadores de acesso.
Martin Fowler traz um padrão de design, que propõe unir o comportamento aos dados, deixando de lado anemia e dando poder ao domínio.

"This is often a good thing because this data and the behavior that manipulates them are tightly coupled: changes in one cause changes in the other, understanding one helps you understand the other." - Fowler, Martin.

Nas palavras de Martin Fowler, esse padrão (também conhecido como TellDontAsk) é frequentemente bom porque traz o comportamento para perto dos dados, facilitando a manutenção e o entendimento das regras de negócio.

Agora estamos garantindo que vamos entregar um objeto selado, além do acesso controlado de/para informações. Ainda, se precisarmos alterar alguma regra de negócio, ou adicionar comportamento ao domínio, está tudo bem próximo para dar manutenção e facilitar o entendimento.
Em programação, nem sempre existe o certo ou errado, mas permanece o questionamento: o que é encapsulamento pra você?