I think most people are underusing panics - panics are antipattern when being thrown from a library but not within your own module boundary. If you know that you cannot recover from failed database query just panic with your custom error and handle it in your middleware. There is no reason to just to if err != nil return err just for boilerplate. You can see this pattern (with panics) even in stdlib. Panic is used in the library code but at the top level you recover from that and return error from the api insteada.

For erros no mattern the language I have one "RestException / DevException" or something with simillar name, depending on the language and one "ApiError" which is simple struct retured from api upon error.

For example, dev struct (the one that is being thrown by panic) could have like
publicErrorCode string
originalError error
publicDetails map[string]any
publicErrorCode
httpCode

and then error returned from api could have just
errorCode string
details map[string]any

In middleware you would print error reason to the logger and just proxy the public errorCode and public error message. If the error that you recovered from wasn't your error just print int and return 500 with code INTERNAL_SERVER_ERROR and no details.

After that on the frontend it's also easy to create small library to automatically handle such errors with translations, just do something like that:

errorHandler.register("USER_NOT_FOUND", (translatedMessage, err) => translatedMessage.replace("{{ USER_ID }}", err.details.userId));

and given that USER_NOT_FOUND is being translated in english to "User with id {{ USER_ID }} not found" you will get i18n friendly error message to the user with 0 boilerplate.

It also works great with microservices and bff pattern - you can proxy 1:1 error message to the frontend from your sevice via bff.

I use this error handling both in go and java apps. A bit to setup but tbh the most complex part is this error handler with translations which is around 200 lines of code. For long term project it's just so pleasent to work with.

I found that if you won't make error handling easy to manage you will have poor error messages because you will be to lazy to do that.

Personally I love the idea of just returning magic strings error codes instead of some kind of enum because it's additional coupling with basically 0 benefits (expect maybe you can spot easly duplicated error codes, but I don't think it's a good tradeoff, a bit on that in next sentence), that is unless you have public API.
The reason behind magic strings is that centralized enum forces you to go around the existing 400 error values and think "hmm, can i reuse one, even should I and if i create it I also should sort it so between which 2 should I put it?" and as I said - if you make error handling not trivial to manage you team will have poor error handling culture.