Having read that article as well, I now am even more convinced that my original prediction of not bothering to spend time learning Emacs was correct. The logic of even the undo system is a “big brain” exercise. I’ll admit that VIM has similar problems but at least it’s universality has served me well, whether I’m working on embedded or ssh’ing into a random server.
undo-tree is an official Emacs package, but it's not installed by default. You can still stick to standard Emacs undo...
...which arguably is even more confusing, because "undo" and "redo" are the same operation. As long as you keep undoing your changes, it works as everywhere else, but when you stop and do anything else - change something, or even navigate around - all the undos you just did become part of undo history. This means you can now redo them with undo operation - but it also means that, to go further back in undo history, you need to first undo all undos, then undo the changes again, and then continue past the point where you were.
Best I can say about this is, it at least doesn't throw away data early. But otherwise it's a super-confusing legacy, which is why undo-tree is one of the first packages I install on a fresh Emacs build.
If my description of Emacs built-in undo is confusing, there's actually a better one in undo-tree readme, where the author compares standard undo/redo systems, Emacs undo chain, and undo-tree. If you're curious, see https://elpa.gnu.org/packages/undo-tree.html, search for "Undo systems".
As for understanding undo-tree, I'd say it becomes instantly obvious once you run M-x undo-tree-visualize on your buffer - it renders you the tree in graphical form, and navigating it applies the undos/redos.
Emacs has a bunch of such "weird" legacy concepts, but it's a wash really - half of the time, it's something confusing as undo. Other half, it's something much superior to what's used in mainstream editors/IDEs. There's stuff to learn, but then, Emacs is an editor for a lifetime.
