O espaço de armazenamento é barato e, portanto, esse não é um argumento muito convincente sobre por que você deve ou não fazer o check-in de arquivos.
Em vez disso, você pode recorrer ao objetivo do SCM. Cada arquivo rastreado pelo SCM representa alguma necessidade de gerenciar as alterações distribuídas paralelas que sua equipe está fazendo. Nada disso é realmente aparente até que dois membros da equipe tentem alterar o mesmo arquivo. Resolver essas mudanças é o objetivo do SCM, evitando a substituição acidental do trabalho de outro desenvolvedor e, esperançosamente, automatizando o processo de mesclagem dessas alterações.
Mesclar arquivos binários geralmente é um desafio real, porque não há uma maneira sadia de uma ferramenta de mesclagem genérica adivinhar como um arquivo binário mesclado deve funcionar. Ele não sabe o suficiente sobre como os índices ou ponteiros de deslocamento no arquivo funcionam, a menos que sejam especialmente projetados para reconhecer esse tipo de arquivo específico.
Isso significa que cabe ao desenvolvedor mesclar o arquivo binário manualmente e depois informar ao SCM que o arquivo foi mesclado. Como é um desenvolvedor fazendo isso, a mesclagem pode não cobrir todas as alterações dos check-ins anteriores e, como o arquivo é binário, não há uma maneira automatizada de verificar a mesclagem.
Para formatos binários que realmente representam fontes de projeto, como ativos de arte, essa é uma etapa lamentável, mas necessária. No entanto, os resultados da compilação não são fontes. Não há necessidade de mesclá-los, porque as fontes podem ser mescladas e uma saída de compilação resultante pode ser regenerada. Rastrear e gerenciar essas alterações é 100% desperdício. Desperdiça os recursos do SCM, embora não exageradamente, mas também desperdiça o tempo do desenvolvedor superando as falhas esparsas de mesclagem. O tempo do desenvolvedor é muito caro e qualquer coisa que o desperdice é um câncer.
Por outro lado, há um caso específico em que as saídas da construção devem ser arquivadas. Qualquer versão do projeto que já tenha sido enviada ou implantada provavelmente deve ser mantida indefinidamente. Ter uma cópia exata de bytes em bytes da compilação real com a qual um cliente está tendo problemas pode facilitar muito o suporte a esse cliente, pois você terá a versão exata que ele possui.
Esse backup provavelmente não deve estar no mesmo repositório que o código-fonte, pois eles geralmente seguem agendas diferentes e têm estruturas basicamente diferentes.