> that error should be managed by its caller

Objectively false. Correct answer: the error should be managed by the code that makes sense to handle the error.

> Any other approach means callstacks are unpredictable

Also false. I use conditions regularly, and my callstacks are very predictable - errors bubble upward through the call tree until they're handled. There's nothing simpler.

> which makes a program way way harder to model

Also false. I have no problem at all modeling and understanding my code rife with conditions.

You're wrong on every point. I don't know how to speak to you given the strength of your conviction, so shrug

I think the fact that you didn't actually refute any of my points speaks volumes about which of us is correct.

What do you mean by "conditions"?

> errors bubble upward through the call tree until they're handled. There's nothing simpler

Between

    output_a := f1(input_a)  // f1 throws exceptions on error
    output_b := f2(output_a) // f2 throws exceptions on error

and

    output_a, err := f1(input_a)
    // inspect and deal with err
    output_b, err := f2(output_a)
    // inspect and deal with err

it seems uncontroversial to me that the latter is less complicated than the former, and easier to model control flow paths.

Exceptions make sense in a lot of contexts! Just not services, servers, or long-lived processes.