Earlier quoted context omitted.
Nevertheless, many of the design decisions make sense in that context. For example: the difference in initialisation of simple data types vs slices and maps. For an application programmer these are weird inconsistencies. But they make sense in the domain. Or the way error handling works. Very tedious to have to do-check, do-check, and not be able to have automatic upwards delegation. But in system programming it's ab…
I don't do anything quite so tedious in my Go-based webserver projects. For functions that can return errors that I don't have a way to recover from (db calls, for example), I use a simple rapper function that automatically logs errors and panics. That doesn't seem to me like much of a source of difficulty or complexity.
That being said, I've followed a similar pattern in writing Go web apps. I passed errors upwards from their originating site to the HTTP handler functions, because that was where the error handling was possible with the best context.