His presentation on his billion dollar mistake is something I still regularly share as a fervent believer that using null is an anti-pattern in _most_ cases. https://www.infoq.com/presentations/Null-References-The-Bill...
That said, his contributions greatly outweigh this 'mistake'.
Without things like null pointers, goto, globals, unsafe modes in modern safe(r) languages you can get yourself into a corner by over designing everything, often leading to complex unmaintainable code.
With judicious use of these anti-patterns you get mostly good/clean design with one or two well documented exceptions.
You just don't need it but it isn't there as some sort of "escape hatch" it's more out of stubbornness. Languages which don't have it are fine, arguably easier to understand by embracing structure more. I happen to like Rust's "break 'label value" but there are plenty of ways to solve even the trickier parts of this problem (and of course most languages aren't expression based and wouldn't need a value there).
The OpenJDK HashMap returns null from get(), put() and remove(), among others. Is this just because it hasn't been reviewed enough yet?
Code reviews 'somehow' strip out poorly thought out new uses of escape hatches.
For your example, it would be an use of get, put or remove without checking the result.
Language-level safety only protect against trivial mistakes like dereferencing a null-pointer. No language can protect against logical errors. If you have untrusted people comitting unvetted code, you will have much worse problems.