> it was important to get as much information from a single compiler run
That's a good point. I remember debugging a core dump... in hex... and going and circling memory addresses with a red pen and chaining them together until I found the problem.
When I started being exposed to and interested in computers around 1982, I inherited a stack of Creative Computing magazines dating back to maybe 1978-ish.
I remember reading about these error message contests in Creative Computing.
Today, I understand why that was. In the olden days, it was important to get as much information from a single compiler run, because interactive computing wasn't universal. Programmers had to share a machine and submit programs in the forms of decks of punched cards to a job submission window. You would not want to fix one error per round trip.
This means compilers had to be smart about error recovery: to try to repair the program after an error, and then keep going to get more information out of it. Whenever error recovery inserts a token into the program (like a suspected missing closing parenthesis), it is making the program longer, and risks confusing itself and creating a runaway loop that has to be curbed somehow.
I suspect the best solutions to these contests must have been exploiting features of error recovery; tricking the compiler into creating a cascade of errors out of something small.