The kernel, and OpenSSH to name another project, is full of random crud nobody noticed. Everyone does their best to review patches and ensure things are sane when going in, but there's a lot of change in projects at scale, and sometimes the standards one patch wrangler has are different from another. Mistakes happen.
If at-patch time is your only code review, you've got problems. If your code base is too huge to look over frequently you've got problems.
And context is important as well. Worrying about sha-exploits in an environment like this is like wondering whether you watered the plants while the house burns down. The security-theater troupe wails like there's no tomorrow when their buttons get pushed. As Linus, said, given the context and the risk, its of almost no consequence.
I'm in agreement with Linus, but it also highlights problems with code-bases this complex. We depend on code being readable to spot malicious activity. Generating a SHA1 collision to jam in a very subtle bug is highly improbable, and might even be unfeasible if the diff is small enough.
There's certainly a concern if your code is more opaque, as is the case in this bug. If you're taking in raw asm.js code, for example, from various sources...
If at-patch time is your only code review, you've got problems. If your code base is too huge to look over frequently you've got problems.