I see what you mean about the messy mental model, and I do 100% agree that in a well designed system most problems should have one obvious best solution. That said, I'm not sure that's a fair criticism of git.

For instance, in this case, as mentioned below, the author of the article should have just reverted the commit where he checked out the files, then done a normal merge. If you're thinking of everything at the commit level, it's pretty much the obvious thing to do. The first obvious thought is to just backtrack (as mentioned in the article), then once you realize that's off the table (since the code is out in the wild) the very next obvious idea is to revert. Revert is what you do when you can't just undo. It's not even as if his commit involved any merges, so the revert is super easy.

I guess I just don't agree that experts would have a hard time finding the simple solution - it was the first thought that popped into my head, and I read the article mostly looking for the explanation for why he didn't just do it.

While git does provide near complete control, you almost never need to use more than the basics, and it doesn't have to be confusing.

EDIT: Just to make very clear why I think the solution is obvious, the first thought that I think will occur to almost anyone is, "if I can just bring the master branch back to its prior state, then I can merge like usual". The beauty of git is if you can form a coherent idea like "bring the master branch back to its prior state" then you can probably do it, and it probably isn't hard. The mistake the author made was to have that thought, and then instead go off down a rabbit hole, and throw out the original simple idea.