1) This is kind of invariant failures (logic errors that should never happens) and handled by panics in the same way as C++ exceptions.
2) In most cases Result<T, E>/Optional is returned from a heavyweight operation (I/O, dictionary lookup, etc) compared to an easily predicted error checking branch.
3) Probably this is problems of a type system or design, not an error handling strategy.
4) Good luck of getting a stack trace of re-thrown (propogated) exception in C++.
Exceptions are not too bad, but they are very often misused.
You know how GOTO is real bad? Well, using exceptions for flow control* is basically a thinly disguised GOTO.
Also, constructing an exception object, with the full stacktrace etc., is a pretty heavy operation and can cause big performance issues. But it's mostly the first thing.
* Which is an important distinction. Flow control exception are recognisable because you intentionally throw an exception and expect it to be caught by a particular catcher to process it in a particular way - much like a GOTO, and with all its fragility. In the proper usage of exceptions, when you throw an exception you don't care which line of code catches it and when you catch an exception you don't care which line of code threw it.
Believe it or not, I was just working on a script this weekend that was becoming a nightmare to debug. And when I realized that I had been lazily using exceptions as control flow, this really hit home.
Exceptions are not too bad, but they are very often misused.