I'm still afraid that I could be stuck needing a variable that's scoped to some other block.

That's a headache in a big ball of mud, of course, where the code is not modular and tightly interdependent. By keeping concerns separate and designing clear interfaces you can avoid that.

That's why structured programming was introduced some 40 years ago.

Complexity increases as scope widens. If you have references to a variable throughout a 3000 line script, then you need to understand all 3000 lines to know how that variable is used. Multiply this by the number of global variables.

On the other hand, if you package functionality into smaller units, all you need to understand is the interfaces provided by each unit. A well designed unit would present an intuitive interface and hide a lot of implementation detail. If the interface is well thought out, the implimentation could easily be changed without affecting any other code.

If I had to maintain that program, my first inclination would be to refactor it into several smaller units that could each be understood on its own. If I didn't have the time, I'd locate all of the globals, declare them in one place, and write a subroutine to initialize them. I'd then call this initialization routine at the beginning of the loop. After I got this done and put the program to use, I'd go back and refactor it so it could be properly maintained and extended if necessary. Under no circumstances would I attempt to extend code like this without refactoring it first.