This person just does error checking, not error handling. Every single example in this post is a bare `return err`. At least wrap the error like `return fmt.Errorf("could not do foo: %w", err)`.
I do think that what seems obviously true and categorical in the absence of concurrency is quite a bit more subtle when concurrent. It’s obvious when rewriting the kind of chains where ‘?’ makes perfect sense from sequential to concurrent invocation.
By no means do I think Go is perfect or can’t learn from Rust but I do think it’s important to consider the tradeoffs against Go’s colorless concurrency - it’s a very compelling affordance. Like garbage collection it’s easy to show the pros and cons in a codebase the size of a demonstration but at scale it’s a decision with pros and cons.
Note that you don't need custom error types, just exported Error instances. These were in use even before wrapping was introduced with Go 1.13 (2019); one had to compare or type-assert directly instead of unwrapping.