Global variables could be stored at the top of the stack analogous to a local variable that just never gets deleted except when program ends. But this requires incrementing the stack pointer for each global variable, even though they will never use the stack pointer (because the stack will never grow or shrink in that region, it is persistent scope throughout program runtime. ) Is the rationale for placing these variables instead in a different section (that has to be added separately in the CPU architecture, adding some complexity since it is another part) that they simply do not need the mechanisms built-in to the stack (stack pointer specifically)? Historically, was a separate "global variable section" added in early-on, or did computers use the top of the stack (or bottom, depending on design and what way it is incremented) for that?
The global data variables go in the data section almost by definition. All the features you would want — initialized data like strings literals, other constants, arrays, etc.. (pre-initialized if you will, by the loader from the program file's data section, i.e. rather than by executing program code), being able to take the address of data within that initialized data (data initialized as pointer to other data), same for code being able to refer to data, labels in data that are constants, "common" data, etc..
Historically, was a separate "global variable section" added in early-on, or did computers use the top of the stack (or bottom, depending on design and what way it is incremented) for that?
Historically, the data sections came first, and computers did not have stacks. Stacks were only added later as the acceptance for recursion became prominent in software, and hardware design followed software evolution. (In much older systems, code & data went together in a combined program "core" image.)
As mentioned above, these data sections support initialized data, a necessity for even the most early programming. There has never been a reason for the stack to support these capabilities, given the (global) data section already does.
I assumed nested functions could access the above function.
If by nested functions you mean statically nested (e.g. enclosed/embedded; functions that are defined within the scope of another function), that can be done provided the runtime function call mechanism provides for a "static link" that refers to the enclosing scope. Languages like Pascal have this. (The static link is passed as a hidden parameter, much like this in OOP languages.)
In Pascal, this mechanism mixes access to dynamic call chain, with access to enclosing function's local variables. It allows for a sort of poor man's object model, in which during lifetime of the function, it is almost as if an "object" is created from its local variables — on the stack — and functions nested with that scope can access the enclosing scope's local variables, similar to objects — but this is an object that disappears when the outer scope completes. (The more general object mechanism of OOP languages doesn't mandate the object be removed when the outer scope leaves, and also allows those objects to be first class — referenced explicitly rather than only implicitly.)
If by nested function you are referring to the dynamic call chain alone, access to caller's variables would usually be supplied as reference parameters of some sort — this, in particular, since in this scenario, the callee doesn't know which caller, so letting the caller provide appropriate parameters that relate to the intent of that particular caller makes sense there.
Why do stack frames not tend to be able to read stack frames one scope up
They can access those memory locations, just isn't supported by a number of popular languages. In order to make sense of how to access variables belonging to the caller, we have to provide extra runtime support. As I mentioned, Pascal provides a model for doing this; these are broadly referred using the term "non-local" (see: https://en.wikipedia.org/wiki/Non-local_variable).