This is silly. We can avoid stack overflow by avoiding unbounded recursion.

In user-space, memory overcommit means that we will almost or literally never see an out of memory error.

In kernel space and other constrained environments, we can simply check for allocation, failure and handle it accordingly.

This is a terrible argument for treating all code as potentially failing with any possible error condition.

> We can avoid stack overflow by avoiding unbounded recursion.

Only if you control the entire ecosystem, from application to every library you're ever going to use. And will not work for library code anyway.

> In user-space, memory overcommit means that we will almost or literally never see an out of memory error.

Have you ever deployed an application to production? Where it runs in the container, with memory limits. Or just good old ulimit. Or any language with VM or GC which provides explicit knobs to limit heap size (and these knobs are actually used by deployers).

> This is a terrible argument for treating all code as potentially failing with any possible error condition.

This is reality. Some programs can ignore it, hand-waving possibilities out, expecting that it won't happen and it's not your problem. That's one approach, I guess.