> So, your argument is that - because you actually see 
    > some code that simply propagates an error, it's easier 
    > to reason about where the error ends up being handled?

Not just where the error gets handled, but how it flows through the execution path of your code -- but, yes.

    > That's like saying you'd rather search for a needle in
    > a haystack than a needle on a platter.

I'm sorry, but I don't see how this follows at all.

    > With Golang, I have to spend way more energy analyzing
    > every caller in the stack because they all touch my
    > error.

Spending time thinking about the error path for all of your code is time well spent, because it's necessary if your code is going to function correctly. Deferring consideration of failure results in dangerous (at best) and/or broken (at worst) systems. I hope this is noncontroversial.