De acordo com o RFC826 (Protocolo de resolução de endereço Ethernet), o remetente deve:
coloque os endereços locais de hardware e protocolo nos campos do remetente
Mas, como você apontou, por que um host usaria o endereço de broadcast em uma resposta ARP? Talvez porque isso possa parecer inteligente: usando o endereço de broadcast L2, todos os hosts da LAN saberiam imediatamente um novo par (IP, MAC) economizando tempo. Na verdade, esse método não é desejado pela RFC (mesmo que se refira à transmissão periódica):
A transmissão periódica definitivamente não é desejada. Imagine 100 estações de trabalho em uma única Ethernet, cada informação de resolução de endereço de broadcast uma vez a cada 10 minutos (como um conjunto possível de parâmetros). Este é um pacote a cada 6 segundos. Isso é quase razoável, mas de que serve? As estações de trabalho geralmente não conversam entre si (e, portanto, têm 100 entradas inúteis em uma tabela);
Também depende do sistema operacional do host adicionar na tabela ARP uma tupla aprendida por uma mensagem transmitida.
EDIT: Conforme declarado nos comentários, o RFC 5227 atualiza o RFC 826 e diz
Em alguns aplicativos da ACD (Detecção de Conflito de Endereço) IPv4, pode ser vantajoso fornecer Respostas ARP usando difusão em vez de unicast, pois isso permite que conflitos de endereço sejam detectados mais cedo do que poderia acontecer.
Um dos usos do broadcast ARP são as respostas gratuitas enviadas por algumas soluções de cluster ou agregação de link (por exemplo, formação de equipes). Esse é o processo que eles normalmente usam quando desejam mover o tráfego de uma interface para outra.
Esse processo atualizará todos os hosts na sub-rede local (incluindo o gateway) e fará com que os comutadores L2 atualizem suas tabelas de endereços MAC. O resultado é que todo o tráfego deve passar para a nova interface de maneira fácil e rápida.
fonte