Transporting and checking for errors throughout the call graph definitely isn't free. Simple exception unwinding isn't very expensive either - store handler info on the stack and use stack frames and it's just a linked list search. Keep popping until you're done. Freeing locals in a way compatible with the language semantics along the way is the main tricky bit. But you have that cost with error results too, it's not extra.

The real cost is that exceptions force the compiler to be pessimistic and pedantically cope with exceptions everywhere. I really don't think there's much win at all, compared to that, in return values the compiler forces you to check. And if you skip the checking, that's a different kind of pain.

Checked exceptions is a different but related story. I think they're a fine idea in the small but appallingly bad in the large; when glueing together 30 different libraries with their own exception types, everything end up throwing anything, particularly when some higher level abstractions have been applied, like iterator streams or monads. Forced return code error checking like Rust's is isomorphic with checked exceptions. It is my biggest worry for the language.

That is, the problem isn't performance - the isomorphism shows that there is no necessary difference when rules are consistently applied - the problem is Java was a good demonstration the checked exceptions were misguided.