When git became successful, there were scant few other options with a comparable feature-set regardless of speed.
Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems.
I'm unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more. This is a stark contrast to vgo which is intentionally solving fewer problems than other modern dependency management tools.
In addition, git must be performant enough to handle a git repo (namely the linux kernel, its original usecase). Beyond that, I think there's no evidence it intentionally cut features or complexity to be faster.
In the case of vgo, it cuts additional user-facing features in order to be faster, but there's 0 evidence that the speed matters, that there are any go projects in the world that cannot be solved quickly enough with an approximation of a sat solver.