Generally, I wait for gameplay footage from official and unofficial sources before committing to buying a game. I have a number of accounts I follow on other social media platforms that keep me updated on new games I might be interested, but none of them are reviewers outside of a quick 30-second blurb on socials or their Steam Curator account.
If I’m leaning buy but still hesitant, I’ll generally pick it up and play for a bit to see if I’ll keep it.
I don’t find that my tastes align very closely with any reviewer, so I generally steer clear of them. If there’s any kind of massive community criticism, there’s bound to be plenty of people shouting about it online which makes it easy to take into consideration (whether to ignore it or not).
I don’t like it, but if they’re part of the project files, then they belong in version control. I do worry about the challenges of combining the difficult-to-merge nature of binaries with the distributed workflows that Git encourages. While data doesn’t get lost, the inability to merge them may mean that someone needs to spend extra time re-performing their changes if they “lose” the push/merge race.
Game engines have been doing a better job of transitioning away from large monolithic binaries by either serializing them in somewhat mergeable text files or at least splitting them into large numbers of smaller binaries to reduce file contention.
Git LFS does offer the ability to off-load them from the repository, reduce download and checkout times as well as the ability to lock files (which does introduce centralization…), but it doesn’t seem to be as ubiquitous and can be more expensive to use, depending on the team’s options for Git repo providers.
Note: I assume you mean binaries as in “non-text files”, not build artifacts, which definitely don’t belong in version control at all.