Como tegbains apontado em um comentário, zfs send streams não se beneficiam de qualquer deduplicação no nível de armazenamento em vigor . Eles também não se beneficiam de outras configurações; é por isso que zfs send | zfs receive pode ser usado para migrar dados para novas configurações que, de outra forma, só entrariam em vigor depois que os dados fossem reconfigurados - como uma desduplicação de ativação ou desativação ou alteração de algoritmos de compactação.
Este é o principal motivo pelo qual o fluxo de envio do zfs se torna muito maior que o espaço de armazenamento alocado. Uma razão provável para isso no caso específico da deduplicação, além do princípio da menor surpresa (se você precisar de um), é que a desduplicação (especialmente em no ZFS) é muito cara e foi tomada a decisão de que os fluxos de envio zfs devem ser recebidos em sistemas com especificações mais baixas.
Seus dados mostram aproximadamente 2,36 TB alocados, com uma taxa de desduplicação total de 2,87x. A multiplicação quantitativa destes dois números produz 6,77 TB, o que é suficientemente próximo dos 6,50 TB estimados para ser um valor razoável. É certamente digno de nota que o valor de 6,50 TB se relaciona a um instantâneo no sistema de arquivos, enquanto o valor de 2,36 TB * 2,87 está relacionado a todo o pool.
Se a implementação do ZFS oferecer suporte a essa opção, você poderá ter alguma sorte com zfs send -D (gerar o fluxo de envio zfs desduplicado).
Observed w/ ZFS on Linux 0.6.1.
Não está diretamente relacionado à sua pergunta, mas sugerimos a atualização. O estábulo ZoL está em 0.6.4.1 até o momento desta publicação (junho de 2015), e houve numerosos aprimoramentos e correções desde a saída do 0.6.1 em março de 2013.