Аппаратный стек тогда бы содержал только один указатель на фрейм и адрес возврата.
Либо даже адрес возврата был бы тоже во фрейме, например первым.

Да, это дополнительная косвенность, но кого это вообще волнует в наши времена быстрых процессоров?
https://stackoverflow.com/questions/26741925/is-frame-in-jvm-heap-allocated-or-stack-allocated

Зато все значения переменных хранились бы в памяти, и к ним можно было бы осуществлять одинаковый доступ (например при сборке мусора).

The benefit of this approach is to have a single memory management for everything including thread stacks.

А раньше, говорят, выделяли:
https://softwareengineering.stackexchange.com/questions/113019/why-does-garbage-collection-only-sweep-the-heap

that's not the popular approach these days. Java's JVM and Microsoft's CLR use the hardware stack and contiguous memory.

там же:
«It is just an accident of history that we happened to decide for a few decades that languages with activation frames that are created and destroyed in a strictly ordered manner were fashionable.
Since modern languages increasingly lack this property, expect to see more and more languages that reify continuations onto the garbage-collected heap, rather than the stack.»