This would not, in any way, prevent a SolarWinds scenario - the releases were properly signed in that attack. You'd have to have a second, separate, build chain rebuilding releases to compare output hashes to catch it.
What I personally tend to prefer is uploading private (as in, not widely published, not that they're hidden) package repositories. Gitlab, at least, has several built-in package repositories (NuGet, maven, PyPi) that can be used for uploading/hosting these kinds of things, and I believe several other CI systems do as well. And in some cases that's not necessary - recent versions of cmake, I believe, can grab git repositories as project includes (assuming the referenced project also uses cmake).
I personally feel no build output should ever be persisted to a repository, and no third-party binaries if you can avoid it. Back when I made my few contributions and also saw the earlier git/svn debates, my feeling was that an artists'/testers' script was the way to go, too. I think my only recommendation here is to make it so that you could pass version numbers to be able to work against a particular build (just stating what I assume was implied). For that matter, it's possible to install hooks into various parts of git (I don't know about svn, but possibly there too) - UnrealEngine, for example, has a script that you're supposed to execute on first clone; thereafter, any time you switch branch or pull updates, it downloads the relevant third-party dependencies and common content.
I personally prefer working with git, being a programmer, because it makes diffs and branching so much easier for text assets. In most common cases, assuming submissions are based on branches/pull requests (instead of submitted diffs), there's usually not much visible difference between git and svn, though - it's only once you have multiple people modifying the same file that git and prs really help. Other than switching typing `svn` for `git`, I don't think artists would really be affected.