Bazaar on the slow track

A "clean" history (meaning "to the best of my knowledge, every change transforms program X1 into a strictly better program X2") means that you can take advantage of one of git's main features when you do find a regression.

Bisecting.

If you do break something, "git bisect" requires ten compile-test-run cycles to find the culprit, among a thousand changes. Or twenty cycles if you have a million changes. (OK, more like 13 and 30, because history isn't linear, but you get the idea.) If you try to keep track of that manually you'd go bonkers.

Of course this isn't restricted to git. bzr and hg also implemented the command. The idea was too good not to. ;-)
I don't know how well they do in finding reasonable bisection points in a complex revision graph; git's algorithm is very good these days.