O meu entendimento sobre a vantagem de passar as ações pelo construtor do Builder é que ao instanciar a sua classe, o consumidor sempre será lembrado de que existe a possibilidade (porque ele pode passar uma coleção nula/vazia se o Builder permitir) de executar ações após a criação do objeto desejado (nesse caso, NotaFiscal). Além disso, o Builder pode com o uso do construtor indicar se é obrigatório haver itens nessa coleção para quando instanciar a classe no método Constroi.
Com um nome de parâmetro no construtor que revele a intenção dessa coleção (por exemplo, acoesASeremExecutadasAposCriarNotaFiscal) o consumidor pode implementar um código para o Builder menos suscetível a erros como por exemplo lançamento de exceção devido a ausência de alguma ação ou outro comportamento inesperado.
Por outro lado, se tal configuração no Builder estiver disponível por meio de um método, talvez o consumidor consuma o método Constroi sem ter o conhecimento de que na construção do objeto tal comportamento (a execução de ações) esteja disponível (ainda mais se a lista de métodos for considerável no IntelliSense).
Uma outra alternativa - para explicitar para o consumidor de que tal coleção de ações pode ser consumida após criação do objeto desejado - é solicitar como parâmetro do método Constroi.
Acredito que em ambas as alternativas conseguem explicitar melhor que o comportamento do método Constroi há um conjunto de ações que podem ser executadas após a criação do objeto. Ainda sim, minha preferência (questão de gosto do mantenedor do Builder) entre elas é o construtor pois entendo que na legibilidade da implementação do consumidor para utilizar o Builder ficará melhor o método Constroi sem argumento do que com argumento.
