The reason git won was in part due to the success of GitHub. It was the first code sharing platform that wasn't a crap.
Once open source projects started moving to it from older platforms (Sourceforge, Trac, etc), developers who might not have cared so much about VCS flavours followed.
Centralized version control systems like Subversion are oriented around "committer permissions". Giving someone commit access incurs friction (waiting for a human to respond) and risk (potentially unwanted changes).
None of the old platforms like SourceForge implemented the concept of cloning a whole repository. Even if you made your own clone (manually or otherwise), what good would that do? Your copy would diverge from the upstream and can never be automatically reconciled. You would be forever doomed to sending patches to upstream, and calculating diffs from upstream to apply to your repo. Or just replacing your clone with the upstream's history after your patch gets accepted.
Git natively supports multiple asynchronous repos representing the same "project" because its history is designed around a directed acyclic graph (DAG) structure. You don't need the upstream repo's permission to make your own clone and commit some changes. After you diverge from the upstream, if you solicit them with your branch and they accept, then both of you can converge once again - whereas this is impossible in a linear history model like SVN.
Once open source projects started moving to it from older platforms (Sourceforge, Trac, etc), developers who might not have cared so much about VCS flavours followed.