I'm obviously not the person you responded to, but one thing to note is that the stack is going to be a more useful source of debugging information if the function call stack is encoding the logic of the program, which I would assert is more often the case in imperative style programming.

Imagine for example a state machine implemented two ways. In an imperative style where you have a big if STATE_IS_X /then function_x() /else if STATE_IS_Y ... tree calling a function for each state. Secondly in a functional style where you have a pattern match on a list of tuples of (state, function). In the first case the stack tells you exactly which state you were in and which function got called. In the second case the call stack will look the same in each case because you just match on the first part, unpack the second part into a variable and call the function in the variable.

I guess I see what you're saying, but shouldn't it be evident which function got called based on the next stack frame up? When I look at stack traces I guess I'm usually just trying to figure out the sequence of calls so that I can know where to look for a bug, but if I needed to inspect state I would probably be doing it in a debugger.