Yes, because each level is (hopefully) there for a reason, and provides a deeper context about where and why the error occurred.

If your contextual information is too repetitive and redundant, it may be the time to refactor your code and remove the unnecessary layers.

It reminds me of A Philosophy of Software Design:

The utility of a module (or any form of encapsulation such as a function) is greater, the smaller the interface relative to the implementation. Shallow ve deep modules.

Error handling might be a proxy to determine the semantic depth of a module.

Another perspective: (real) errors typically occur when a program interacts with the outside world AKA side effects etc.

Perhaps it’s more useful to lift effects up instead of burying them. That will automatically put errors up the stack, where you actually want to handle them.

This perspective also made me think of another advantage of Go error handling over traditional try/catch logging:

In other programming languages, when doing some asynchronous work in some background worker or whatever, exceptions become useless as error reporting mechanisms, because stack traces don't correspond to the logical flow of the program. I remember Java's Spring to be exceptionally painful in this regard.

In Go, since errors are values and you're expected to add context information whenever appropriate, you can shift and shuffle those errors between stacks, and still keep useful context information when you eventually read those errors.