Não sei se perceberam, mas o build além de ter aumentado as classes foram em torno de 6 a 7 linhas de código copiadas em todos os métodos de teste. Pensando na proporção de es ter muitos outros testes, qual a vantagem vista nesta implementação?

Fala Alan, tudo bem?

Retirado do livro Java Efetivo: "O padrão do construtor é uma boa escolha ao projetar classes cujos construtores ou fábricas estáticas teriam mais do que um punhado de parâmetros."

Se, for exemplo, uma classe tiver vários parâmetros opcionais, não é difícil encontramos uma classe com uma lista de construtores em que cada parâmetro adiciona um novo argumento ao construtor da classe:

Pizza(int size) { ... }        
Pizza(int size, boolean cheese) { ... }    
Pizza(int size, boolean cheese, boolean pepperoni) { ... }    
Pizza(int size, boolean cheese, boolean pepperoni, boolean bacon) { ... }

O problema com esse padrão é que, uma vez que os construtores tenham 4 ou 5 parâmetros, torna-se difícil lembrar a ordem necessária dos parâmetros, bem como qual construtor específico você pode querer em uma determinada situação.

Nesses casos usar um Builder (apesar de acrescentar mais linhas de código) resulta em um código fácil de escrever e muito fácil de ler e entender:

Pizza pizza = new Pizza.Builder(12)
                       .cheese(true)
                       .pepperoni(true)
                       .bacon(true)
                       .build();

O padrão builder é flexível e é fácil adicionar mais parâmetros a ele no futuro.