Here's a good article form rob pike on one way to look at how Go can handle errors https://go.dev/blog/errors-are-values
You, the writer, pass around errors manually so that the reader, who interfaces with the code 10x more than the writer, is able to reason about the code. Go's errors handling sucks, but I don't think everyone has the same opinion on why it sucks; I personally think that sum types should be added to the language making it impossible for errors to be silently ignored.
Exceptions, while convenient, require too much discipline to use cleanly.
Here is a link to Google's C++ style guide, which discourages exceptions with pros & cons:
https://google.github.io/styleguide/cppguide.html#Exceptions
It's your 25 years of coding, vs the several thousand man-months of Google's C++ codebase. That said, I don't deny that some people use exceptions with little mental overhead. I've been told about very high performance and readable trading software that made use of exceptions. My main gripe is that it they require discipline to use correctly, almost everyone uses them differently, and they make code harder to reason about. I would prefer a language that doesn't need an IDE to locally reason about some piece of code.
They concluded against them due to problems integrating into legacy code which is fair enough
And don’t forget the principle use case of C++ - it is a low level language. While exceptions are pretty cheap overall, they can be expensive in some niche cases which do happen more often in C++ than in python.
I really haven’t heard a good case against exceptions per se — they make it possible to handle every error at an appropriate place. And bubbling the error up to possibly a much higher place is exactly the needed approach many times (e.g. returning a http error code on an unrecoverable mistake)