Storage space is cheap, and so that's not a very convincing argument for why you should or shouldn't check files in.
Instead, You can appeal to the purpose of SCM. Each file that is tracked by SCM represents some need to manage the parallel, distributed changes your team is doing. None of that is really apparent until two team members try to change the same file. Resolving those changes is what SCM is really for, preventing accidental overwrite of another dev's work, and hopefully, automating the process of merging those changes.
Merging binary files is usually a real challenge, because there's no sane way for a generic merge tool to guess how a merged binary file should work. It can't know enough about how the indexes or offset pointers in the file work unless specially designed to recognize that particular file type.
That means it's up to the dev to merge the binary file by hand, and then tell the SCM that the file has been so merged. Since it's a dev doing it, the merge may not really cover all of the changes of both prior check-ins, and since the file is binary, there's no automated way to verify the merge.
For binary formats that really represent project sources, such as art assets, this is an unfortunate, but neccesary step. However, build outputs aren't sources. There's no need to merge them, because the sources can be merged and a resulting build output can be regenerated. Tracking and managing these changes is 100% waste. It wastes the SCM's resources, though not terribly much, but it also wastes developer time getting past the spurious merge failures. Developer time is very expensive, and anything that puts it to waste is a cancer.
On the other hand, there is a particular case where the build outputs should be archived. Any version of the project that has ever been shipped or deployed should probably be retained, indefinitely. Having an exact, byte for byte copy of the actual build that a customer is having issues with can make supporting that customer much easier, since you will have the exact version he has.
That backup probably shouldn't be in the same repository as the source code, since they will generally follow different schedules and have basically different structures.