Checked exception need to be handled properly. It depends on the sanity of the API.
However, the standard way how to handle checked exception is a lot easier to maintain than error return values.
The only mainstream language that has checked exceptions is Java, and it is almost universally agreed, even within much of the Java programming community, that checked exceptions cause more problems than they solve.
Of course, unchecked exceptions have the problem that is basically impossible to keep track of what exceptions a function might throw (because it has to document all the exceptions that any functions it calls might throw too, and so on and on.)
In the end, of all error handling mechanisms around, Go is by far one of the best.
Easier to maintain how? I don't think I see it. Return values, at least as a mechanism, are strictly simpler; they do not introduce new control flow. They just use "return." Control always reverts to the caller.
For an exception, you don't know whether it's the caller, the caller's caller, some generic exception handler, or what. It's no fun trying to track down all of the callers of A, some subset of which might not catch exception X, then track down the subset of those callers which catch X.
Otherwise adding or removing error codes seems equivalent to adding or removing exceptions. Same with trying to decide which exceptions/errors to handle or bubble up.
