Stack persistence vs. API simplicity

Yes, currently compilers use stack like this. But nothing is preventing compiler writers to use/allocate stack differently.

For example, LLVM recently implemented "SafeStack" for security purposes. It allocates and uses separate stack for variables that cannot be statically verified how they are accessed (like arrays). This way if somebody will pass bad data into function and buffer overflow will happen, it won't overwrite return address. So nobody will be able to jump to arbitrary location thus preventing many exploit techniques (like ROP).
If you have to explicitly declare that you're going to be referencing data in a "popped" stack frame, there's no reason that the compiler can't just push new stack frames after the ones being referenced.
mmozeiko
Yes, currently compilers use stack like this. But nothing is preventing compiler writers to use/allocate stack differently.

As a slight digression, languages with lexical closures and continuations often require a tree-shaped "stack", usually referred to as a cactus stack. ML is arguably the best example. JavaScript is arguably the worst example.

Also, some languages require multiple stacks for their semantics, although smart compilers can usually compile one of these out or combine them into a single stack. Prolog, for example, usually has a separate stack (called a "trail" in WAM-speak) for undoing variable bindings when backtracking.

The SECD machine, often used to implement Lisp, has two stacks called the "stack" and the "dump". Confusingly, the stack is usually implemented using machine registers and the dump is implemented using the stack.