This is an instance of a more general problem in all software development: tools are created usually to serve a purpose, but when they become popular they end up being used, not because they're a good fit for the problem, but because they're popular -- everybody knows how to use them. The tradeoff (which may be worth making) is the time to learn a new tool vs. the continual cost of using a tool that's not quite right for what you're doing.
...this is not the case for most projects. They want to have a clear source of truth for the code.
Almost none of these thinkpieces about git are saying that Linus was foolish in his approach or that he should have anticipated git becoming the lingua franca for junior engineers at megacorps. Instead almost all of them are talking about git's failing in modern development and bemoaning the lack of a better option, followed by a bunch of people insisting that git is actually awesome as long as you can reason about graphs.
I think your criticism here is actually implicitly already part of almost every discussion about git in modern times.
It just happens so that most software development is more like the Linux kernel and less like game development, so for most software projects git is a good fit indeed, just not for gamedev. Maybe it's worth looking into how CGI studios are managing their data, I guess they have the same problems to solve as gamedev studios.
There are specialized solutions though, like https://www.plasticscm.com/ (quite recently acquired by Unity).
I don't think that is true. Linux kernel development is truly distributed. It is expected that there are multiple completely deployed branches. Most software development using git does have a single point of ownership and a single release branch. It is done on company machines with managed environments.
Game development is pretty much on the opposite end of the spectrum, 99.9% of game project data isn't text (maybe not by number of files, but definitely by file size), and game development also traditionally isn't as extremely decentralized as Linux kernel development.
The problem isn't git, but that it has become so popular that it's now the defacto standard version control system, and people expect it to work for scenarios it wasn't created for (at least people who don't know much about the specific workflow requirements of large-scale game development).