There's a little more nuance to it than that. While git users generally keep a local copy of a repo, collaborating with others is pretty much always done through a central server. Git users could theoretically collaborate without a central server, but it currently a far too manual process to be considered practical. There were a couple of attempts to implement decentralized collaboration in git under the name gittorrent, but those didn't go anywhere. Failure is understandable in this space, decentralized collaboration is a _hard_ problem and the tools to do it are still in their infancy. IPFS is probably the furthest along at this point and they're still a long ways away from having something production ready.
Sure, but it's decentralized in a sense that there's nothing special about any of the clones. If developers lose their shared clone of the repository, they can re-create it easily by seting up another shared clone that anyone can access and push there from their local repos. Nothing will be lost.
"Central" server is not special in any way, other than being readily accessible by everyone in the team.
Some services break this by piling other stuff on top of git that's not distributed (like issues, ci, etc.), but that's not a problem of git.
But in most people's workflows there is something special about the central server: it is the source of truth about the state of public branches. That is why losing the central server is so disruptive. It means you have to re-establish the source of truth somewhere else and get everyone to transition over to that new source.
With a truly decentralized system the source of truth would be content addressable. For example, it could be obtained via a public key rather than a server's domain name.
