Explicit error recovery is not hell, it's a blessing. Much easier to understand and to maintain than exception handling.
I don't know why so often, the immediate reaction to legitimate criticism of this wart in Go is to argue against exceptions, even when nobody has even brought up exceptions as an alternative.
I agree that, probably universally, the people who fervently argue for either exceptions or explicit Go-style error handling don't know about Maybe/Either/Result. Then again, all this is pretty much impossible to replicate in Go.
That said, even something as simple as errors being literal values that you can pattern match on is surprisingly versatile. Exceptions don't necessarily have to be awful weights that spill down all over the call stack, either. They can be distilled to a more basic catch/throw mechanism for shuffling around error properties and states.
What I've seen a lot of is swallowing of errors. For example readFromFile().orElse("") where there is no indication from an outsider that anything wrong happened. A cool feature would be logging any instance of when orElse was the result.
Would be curious how these work in other languages.
Personally I find them essential in particular for larger codebases. They allow for centralised, consistent error handling behaviour. For example paging application support teams only for certain types of errors.
And you can always emulate explicit error recovery with exceptions. So what is so bad about having the flexibilty to accomodate different styles of error handling.