>1. Many state+code objects in software have hidden state - it's called encapsulation.
Normal designers try to MINIMIZE it. You are not only add it gratuitously, but also introduce non-trivial interdependencies between objects.
What if j.jiggle() takes 10 minutes to complete? Then your code would just be losing time if "f.twiddle()" is in error.
>2. Decoupling error handling from the error site (in terms of the programming language syntax) is exactly what exceptions do!
Not error handling, but error _detection_. You can simply forget to check that f's state is OK after the loop. Then there's a problem with compounded errors.
> 3. You could level this argument at pretty much any OOP code, you'd have to be writing pure functional code to avoid this charge.
Nope. Good modern OOP code tries to minimize mutability (it's OK to use mutable objects where it's necessary) - a lot of new OOP languages even have variables that are immutable by default, for example.
> 5. Thread safety is completely orthogonal. Making it thread-safe is no different to making other stateful objects thread safe.
No. For instance "f" object might be immutable except for its "error" state.
BTW, I think that there should definitely be a death penalty for those who abuse do..while loops to emulate "goto".