Which is fixed interactively at the same REPL. You're just restarting a computation instead of resuming it. Rather than recompiling/rebooting the entire program and losing its state in the process.

However, this style of development has taught me to write code that's resilient to such errors in the first place (as it, errors wont leave the program in an invalid state), and the end result is that I feel much more confident putting code in production and restarting computations at the REPL is effectively free and feels the same as using the condition system for the most part.

That's my point--you're restarting the 'computation' instead of resuming it, compared to restarting the program. It's the same benefits you acknowledge, just, moreso.

It depends on the context. Resuming a request handler after the client timed out is no good. Even in CL in those cases you're fixing at the REPL and having the client redo the request.

Or you're developing your function in a sandbox and restarting the computation has no difference to resuming it in the first place.