You can still cache things locally, it's just shouldn't be something the user has to be aware of. What I'm typing now isn't immediately being communicated to the central server every keystroke, there still is local state, but it's still a client-server architecture.
The repos I work on are often smaller than the average webpage, I'm really not buying the idea that in the age of HD streaming bandwidth-concerns are an issue here.
Incidentally none of the teams I've worked on ever even use any git features like bisect. The cult of git means everyone has to use git, even though for most people that just means many hours wasted googling with absolutely nothing to show for it (as in git is strictly inferior than just sharing files across a networked drive for many teams' use-cases).
Caching is trickier than decentralization because it's hard to know when the cache is valid. Fetch/push make that explicit, and not git's concern.
Meanwhile, others work in airplanes and in the woods.
Not using git bisect is your loss. I'm very happy it exists, and wouldn't trade git for just files on network drives.
Yes and pushing 'when do i update to/from the server' onto the user is exactly what I'm complaining about. No other software I use does this. Even software originally built to do things locally allows you to seamlessly update to/from a server nowadays (e.g. working on a cloud document in Word say). And any software built from the ground up to do this tends to have a great user experience (e.g. Figma).
You can absolutely build a system that fetches a git remote whenever it updates, you just need some sort of a notification/subscription system to know when to trigger it.
You can absolutely build a system that pushes (some of?) your branches on every commit.
For me personally, that'd be annoying; every time I talk to the git server, I want to insist on a Yubikey touch.