Terms like "Spaghetti Code" and "Single Point of Exit" are actually throwbacks to that era. Nowadays we call code we don't like "spaghetti code", but really that's a reference to code tied together (badly) with GOTOs and JMPs.
(Today we suffer "ravioli code", in which the code is like a bunch of unrelated, tightly packaged classes, much like a plate of ravioli. However, some OO experts ask justifiably, "But isn't that what OO is supposed to look like?")
"Single Point of Exit" today is just a frustrating refactoring roadbump. A lot of devs I talk to haven't even heard of it, and are aghast when I explain it. But in the old days it meant don't jump out of a code block suddenly & into spaghetti code. Jump forward to the end of the logic, then exit gracefully.
Stretching my memory way, way back, I seem to remember that the idea of bundling code up into procedures was a big leap forward. The idea that you could package procedures into inter-operable, reusable Modules was kind of the Holy Grail of programming.
EDIT: "Self-modifying code" was also a pattern used notably on the original Doom. That's where the program would actually overwrite its instructions with faster instructions based on it's state. When I was a tyke taking a programming course at the Science Museum, my instructor warned us sternly, "Don't write self-modifying code!"
EDIT EDIT: However, before the Internet, word travelled a lot more slowly. The idea of implementing Algorithms and Data Structures used to be a much bigger deal. Today I do sort all the time without even knowing what sort I'm using. But back then you had to code it up yourself. I remember one article talking about programming challenges that used to take days that today we knock out in a half hour, or less. So really concious "algorithmic" and "data stucture" programming would probably be on the list, much more than today.