It sounds confusing, but it's actually really easy to get used and hard to walk away from it. Essentially the undo is just another operation so it can be undone just like everything else, and that's a redo. Imagine the following situation, I wrote a text, but wasn't happy with some part, so I select that part and delete it, now I keep writing but I realised I need some part of what was there, so I undo all of the text that I wrote, select the text I want to copy, and accidentally cut it instead of copy it. In most editors that's it, you're fucked, you just lost your most recent changes, on Emacs undo does not destroy things, it only adds to the sequence. In other words, as a step by step:
Write text
Delete part of it
Write more text
Undo step 3 (most editors that means go back to step 2, so step 4 is in a dangerous space)
Undo step 2 (again, most editors would have actually gone to step 2)
You're now in something that looks like step 2, cut the text you wanted (on most editors because you were in step 2 and did changes you can't ever go back to step 4, because this is the new step 3 and there isn't still a step 4, so undo and redo will undo and redo the cut of that text)
Undo step 6 (you're now similar to how you started step 6 or 2, on most editors you are really on step 2).
Undo again (on most editors that would take you to step 1), this will take you to step 5, i.e. you redid the step 2, so the text disappeared and you're like you were at the beginning of step 3.
Undo again and you undo the undo of step 3, putting you back on original step 4
Like I said, confusing to understand, but it means that you can't ever shoot yourself in the foot by undoing things.
Bizarre that you've hated it for 30 years yet didn't know one of the earliest things users learn about it (that actually is fine to use). Perhaps you should examine why you hate something you're almost completely ignorant of.
Though most jokes and criticisms about Emacs betray complete ignorance of it, so you're hardly unusual.
EDIT: If you use screen or tmux, I suppose that you probably don't need software flow control anyway from a UI standpoint, because both will suspend flow if you enter their copy mode, which acts similarly.
EDIT2: I suppose that the utility of software flow control is probably rather reduced today from its original role. At one point in time, the rates at which data could be sent to the terminal was low enough that it wasn't a particularly large issue to suspend it while interesting information was still on the screen. I certainly remember some relatively-slow terminal systems, especially with control sequences mixed in; BBSes took advantage of the fact that it took time for ANSI art to be transmitted at 9600 baud modem connections or so to make the display of an image something of an animated, vertically-scrolling banner; you'd have banners that were rather vertically-larger than the typical display, but moved slowly-enough to watch as they scrolled by. But today, a large chunk of software can throw text at the terminal so quickly that, unless its performance is otherwise-constrained, one has little chance of stopping flow while the information one wants is visible. Only really useful if the software naturally has stops at useful places and one can suspend flow there, and I don't know what percentage of cases that comes up with. Maybe there's an argument to default to not having software flow control any more.