In over 6 years working in this industry, in projects with anywhere from dozens of users to millions of users, not a single bug I have encountered was caused by a "hidden allocation" causing the process to go OOM. Not one instance.
One of the two examples he cited in his introduction, the Android one, wasn't even caused by an unhandled OOM error. Android by design will kill unused processes if they're occupying memory that the foreground process needs.
If we want software without bugs, removing hidden allocations in languages is far down in the priority list.
The vast majority of bugs aren't are due to corner cases that the programmer didn't think about. Quickcheck and related techniques expose many more bugs than eliminating OOM bugs.
Yes for most userland applications removing hidden allocations is not a concern, which is why for most general purpose programming languages this is way down the priority list.
Most languages make allocations behind your back so that your code can focus on the logic you actually care about since you could not do anything about running ot of memory anyways.
However there are projects where that level of control matters. For those projects C is currently still the default choice, even though it was designed more than 40 years ago. Some choices made back then might be huge liabilities for code we are writing now, because we still need that kind of language. A modern alternative to C could provide a huge value to all of us, mostly through more correct, secure and/or performant software.
One of the two examples he cited in his introduction, the Android one, wasn't even caused by an unhandled OOM error. Android by design will kill unused processes if they're occupying memory that the foreground process needs.
If we want software without bugs, removing hidden allocations in languages is far down in the priority list.