It's not meant to be a local version control system, unless you enjoy running local Kubernetes clusters (which I have to do, but don't enjoy).
It's meant to be the next big thing in version control - no reason not to go for it - which means that it would have to be picked up by the major source control hosters, and since I know what it takes for GitHub to run its infrastructure, I know that it makes much more sense to build something new on PaaS services, not on file servers. Not anymore.
> I already understand git, so does everyone on my team, and everyone that interviews...
Yeah, but do they? That's not my experience, and it's not the experience of most people I talk to about it. Most devs I've asked about it understand the basics of how to use Git, but they're still afraid of it if anything goes wrong. My guess is that the ratio is 20% deeply understand it, and 80% only know what they need to and hope nothing bad happens.
Maybe your team are all a bunch of reflog wizards... that's awesome. And uncommon.
And I almost always get laughs and head nods when I talk about the problems with Git's UX.
> Is large files the main problem this solves?
No, but it's a big problem for gaming companies, who are mostly stuck on Perforce. And Git can't handle them well without the bolted-on LFS. And with the rise in monorepos, more and more enterprises want to be able to store more and bigger files than ever before.
> And maybe requires an internet connection?
Yes, absolutely, it does. So does Git if you expect to push anything anywhere. And if you happen to be doing dev using Azure or GCP or AWS you need one too.
Building something that would become popular in the late 2020's, and assuming that users will have solid Internet connections (don't forget satellite) is what makes sense. If you're still in a situation where you need offline VCS then, Git will still be there.
> Maybe this is for pair programming?
You could use it for that, but pair programming is not a direct design intent.