Old C compilers would first parse declarations, then allocate space on the local stack (usually by subtracting the number of bytes needed from the stack pointer), and go on to compile code, knowing that - from that point on - there's a well defined stack structure (and very often in those days, even a constant offset from the "frame pointer" or "base pointer" which would be copied from the stack pointer at that point)
Introducing additional variables later, means that if you emit code "as you go", you'll be less efficient - which makes no difference today, but was a big thing in the days C was designed; Most compilers back then were single pass, emit-as-you-go. There are relatively simple ways to deal with that even under the single-pass constraint, but in those days and the common compiler construction techniques prevalent at the time, it was considered harder.
There was always an issue of fixups with scope-exiting control transfer like break and goto - however, they are simpler, and don't harm emit-as-you-go compilation to the same extent.
On the other hand, one nice thing about C compilers is that they are _fast_. I always inwardly shudder when I see a C++ file including Boost, because I know the compiler is going to have to chew on it for several seconds every time there's a change.
Introducing additional variables later, means that if you emit code "as you go", you'll be less efficient - which makes no difference today, but was a big thing in the days C was designed; Most compilers back then were single pass, emit-as-you-go. There are relatively simple ways to deal with that even under the single-pass constraint, but in those days and the common compiler construction techniques prevalent at the time, it was considered harder.
There was always an issue of fixups with scope-exiting control transfer like break and goto - however, they are simpler, and don't harm emit-as-you-go compilation to the same extent.