Another useless paper. The deep call stack problem exists in any kind of parallelism. And use multiple processes can be safer but the complexity is actually the same.
Consider an event-based server that returns to an event loop whenever it makes a blocking call. At any point in time, most of the active requests will have a call stack depth of zero, and the rest will have just the frames since they were last unblocked. Contrast that with a threaded server where a request occupies a single, deeper stack for its lifetime.
Or consider an actor-based system where an actor has just a few responsibilities and communicates with other actors with messages. Contrast with a threaded system where the server's submodules have to communicate with function calls.
I don't see how stack depth matters much, though. There are way more important considerations.
You knew someone would say it so I will: it matters on RAM-constrained systems. I'm currently working on a CPU with 384K flash (a lot) and 48K RAM (not quite enough).
Many systems in this class use preemptive multi-tasking OSes in a shared, non-virtual memory space. The question how to pre-allocate stack space is tricky. One non-traditional model is to use run-to-completion threads without stack switching so the problem reduces to estimating your overall worst-case stack usage.
Another popular model is main-loop + interrupt handlers. In a lot of ways that's more like an actor model.
My thoughts were:
1) As we enter the massively multicore era, there will be much bigger fish to fry than a little memory overhead. Clock speeds have topped out while transistor counts are still growing exponentially. Exponential means soon application programmers will be tasked with keeping 100s, then 1000s of cores busy. It's gonna be a giant challenge for PL guys, systems guys, and app guys to make that happen. If an improved concurrency model can get us there, then 25% memory overhead one way or the other will be relatively insignificant.
2) The object liveness issue is an implementation detail of one particular VM. There's nothing but CPU cost preventing VM writers from being a little more clever and marking objects unreachable if they are only referenced by dead local vars in otherwise live stack frames. I don't know enough about it to know whether the CPU cost would be prohibitive, but the issue seems more nuanced than just "threads => deep stacks => +25% mem".