Off the top of my head I can think of two reasons, there are probably more.

The first reason is that these variables may be set by a routine each frame, and then a lot of code uses them during the time of the whole frame. Every interrupt routine that fires during that frame may want to read out the current direction.

The second reason is that, in a real-time embedded environment1 like a console game, it's important to know that you have enough resources to handle the worst-case conditions. One resource is time; you want to make sure that everything you want to perform can be handled in one frame update. Another resource, and relevant in this case, is memory. Whatever happens, you can't run out of memory2. There's no swap space, you can't pop up a requester, or kill off something else. Add to this the fact that embedded platforms like this do not have any form of memory protection, so if you write too much on the stack — game over, man.

The combination of these two makes it reasonable to reserve RAM for variables like this.

1. These platforms still exist today, think control systems for robots, your fridge, basically every "hidden" microcontroller.

2. I've recently worked with an operating system designed for high reliability. It had every type of dynamic allocations removed. No malloc() for you.