Even the article considers "handling" an error to be synonymous with "Adding more text and bubbling it up"!
You can also add additional context to the error before bubbling it up. But yes, that part of the point. Instead of bubbling them up, the programmer should instead reflect on whether it is better than just log and proceed, or completely swallow them. This is what error handling is about.
You can't bubble up an exception, it's done automatically. That's a very important distinction. You can't make the decision to bubble up or not, because you do not have the required information - you don't know whether an exception can be thrown or not at any point. Therefore, you can't say you're making a decision at all.
Explicit error allows you to be able to make the decision.
So it's:
Rely on the programmer to identify that an error was made and in 95% of situations just bubble it up, do something useful 5% of the time, but "deal with" the error 100% of the time OR
Rely on the programmer to identify the 5% of situations where they don't want the error to just bubble up and add special handling for that case specifically.
1. The very fact that adding more text isn't really any more verbose than not encourages you to add more text, making errors more informative.
2. A non-negligible amount of times you do something else: carry on, or do something specific based on what kind of error it was. For instance, ignore an error if it's in a certain class; or create the file if it didn't exist; and so on.
Forcing the error handling doesn't seem to me that different than forcing you to explicitly cast between (say) int and int64. Part of me is annoyed with that too, but then I have PTSD flashbacks from 20 years of C programming and appreciate it.
It makes them almost as informative as languages with stack traces! Imagine if Go had a syntax like python's
raise Exception("bad thing happened") from err