The "useless" instructions aren't for potential stack allocation, they're there so backtraces work. If you don't care about that then you can add -fomit-frame-pointer and they disappear.
Compilers don't default to this because having backtraces on crashes and profiling are more useful than the like 1% speed gain from another available register on x86-64.
Are you arguing that they do work on ELF+DWARF with sufficient extra debug info, when running under a debugger, despite documentation that explicitly says it doesn't work? Because I certainly don't expect my users to have a debugger installed (let alone regularly run programs under one) but I'd still like to get useful crashlogs automatically.
Or are you saying that you could potentially reconstruct a backtrace, if someone wrote code to do so that is smart enough to locate and account for all the stack adjustments in reconstructing where each function stored its return address, including runtime alloca() / VLA adjustments and multiple adjustments in the same function (potentially needing to reconstruct the code flow), just from the disassembly? Because the linked MIPS code is nowhere near that smart, and to my and that author's knowledge, such code has not been written for x86.
Either way, nice in theory but not good enough in practice.
The debugging info is enough to find, for each code address, the offset to the return address on the stack, from which you can find that offset, etc. You don't need a debugger but saving the stack is enough to get a backtrace for a crashed process.
You can have a minified memory dump sent automatically, then symbolicate it on your servers using the stripped debugging symbols. That's what Breakpad does. I'm not sure how well it deals with alloca(), but I've used in on several shipped pieces of C++ software and it worked mostly fine.
Compilers don't default to this because having backtraces on crashes and profiling are more useful than the like 1% speed gain from another available register on x86-64.