Well, either way, the point stands that checking this dependency into source control would not have made any difference since it was malicious all along.
This is an "all else being equal" argument except without saying so explicitly, and it falls apart if that doesn't hold.
Your claim is that no matter whether dependencies' source code is acquired by git-clone or npm-install, then everything related to this attack unfolds exactly the same as it did in the timeline where we live. But as I said in my first comment in this thread the effect of going along with The NPM Way changes how people interact with third-party code.
My contention is that in the universe where dependencies get checked into version control, this is one package that (assuming it ever got created at all) would have been less successful in conscripting others to choose it as a dependency, and that wrt the remaining instances if any where it was approved to be checked in, the question of what effect the mere act of checking it into version control and the fact of its existing there has on its being discovered sooner is non-zero.
But okay, let's go further and use git submodules so that package.json is out of the picture. Even in that case we have the same problem.
Or, let's go even further and vendor the dependency so it is now copied into our source code. Even in that case too, we still have the same problem.
The dependency has been malicious all along, so if we use it in any way the game is already over.