You're looking at a minimal test case, not an example of it happening in real production code. Of course it's obvious in the minimal test case, that's the point.

I've personally written something akin to the following, which triggered no errors (at the time, maybe this is fixed):

    foo, err := foo()
    if err != nil { 
        nil, err
    }

    return foo, nil

The worst part is because all of the error-handling is copypasta boilerplate, your eyes don't look at it. So subtle bugs get through and make it to production. I've seen this one too:

    foo, err := foo()
    if err != nil { 
        return foo, nil
    }

    return foo, nil

Also note that now we've gone from "Doesn't [go] provide compile time check for errors?" to "Well I guess it doesn't check that errors are used, but that would never happen to me."

> Also note that now we've gone from "Doesn't [go] provide compile time check for errors?" to "Well I guess it doesn't check that errors are used, but that would never happen to me."

True, but there was also a "you are right" in between :)

> does that scenario really happen in practice

It does happen, I've seen it several times, and even other insidious examples that linters did not catch. When you're dealing with a code base that is constantly changes, things like that end up happening.