First off, I'm of course interested to see what the future infrastructure of software building next looks like.

> The hard problem is not generating change, it’s organizing, reviewing, and integrating change without creating chaos.

Sure, writing some code isn't the bottleneck. Glossed over is the part where the developer determines what changes to make, which in my experience is the most significant cost during development and it dwarfs anything to do with version control. You can spend a lot of energy on the organising, reviewing, patching, etc. stuff -- and you should be doing some amount of this, in most situations -- but if you're spending more of your development budget on metaprojects than you think you should be, I don't think optimising the metatooling is going to magically resolve that. Address the organisational issues first.

> This is what we’re doing at GitButler, this is why we’ve raised the funding to help build all of this, faster.

The time constraint ("faster") is, of course, entirely self-imposed for business reasons. There's no reason to expect that 'high cost + high speed' is the best or even a good way to build this sort of tooling, or anything else, for that matter.

Git's UI has become increasingly friendly over a very long time of gradual improvements. Yes, Mercurial was pretty much ideal out of the gate, but the development process in that case was (AFAIK) a world away from burning money and rushing to the finish.

Maybe going slow is better?