Over the years, I\'ve always stored binary dependencies in the \\lib
folder and checked that into source-control with the rest of the project. I find I do this les
My own rule of thumb is there generated assets should not be version controlled (regardless of whether they're binary or textual). There are several things like images, audio/video files etc. which might be checked in and for good reason.
As for the specific points.
You can't merge these kinds of files but they're usually just replaced rather than piecewise merged. Diffing them might be possible for some files using custom differs but in general, this is done using some kind of metadata like version numbers.
If you had a large text file, disk usage is not an argument against version control. Same here. The idea is that changes to this file need to be tracked. In the worst case, it's possible to put these assets in a separate repository (that doesn't change very often) and then include it in the current one using something git submodules.
This is simply not true. Operations on that specific file might be slower but that's okay. It would be the same for text files.
I think having things in version control increases the convenience provided by the repo. manager.
This touches on my point that the files in question shouldn't be generated. If the files are not generated, then checkout and build is one step. There's no "download binary assets" stage.