I completely agree; the entire time I'm reading this I couldn't help but feel this was misunderstanding the use of exceptions.
The stated design goal is that the project "never fail and never exhibit undefined behaviour" yet exceptions are exactly for undefined behavior. If you can't allocate memory, if your function is called with arguments that it cannot possibly interpret, or that a fully expected network connection has failed and cannot recover. Those are exceptions. For all your defined behaviors, you can control just as described in the article without exceptions.
There is clearly too many exceptions (and handlers) in the first case and way too few in the second case.