That's not how people commonly use errors, with global variables.

The way code usually looks like is this:

  func foo(arg int) error {
    if arg < 0 {
      return fmt.Errorf("expected >0, got %d", arg)
    }
    if arg > 8 {
      return fmt.Errorf("expected >8, got %d", arg)
    }
    //do stuff
  }

or

  func foo(arg int) error {
    if arg < 0 {
      return errors.New(fmt.Sprintf("expected >0, got %d", arg))
    }
    if arg > 8 {
      return errors.New(fmt.Sprintf("expected >8, got %d", arg))
    }
    //do stuff
  }

In either of these cases, a caller of foo() can at best parse err.String() to see why foo() complained. But there is no way that errors.As or errors.Is help with the majority of errors returned by Go programs.

The problem is that the first-level error in most Go functions is fmt.Errorf(some error message, some args). The idea of pre-allocating an exported global error object (like io.EOF) is very rarely useful, and error structs are very rarely used either, because they require much more ceremony than just returning a fmt.Errorf() (or even an errors.New()) on the spot. But errors.Is is only useful if you take the first option, and errors.As is only useful if you take the second option.

So, in practice, neither errors.Is nor errors.As are terribly useful, and %w just gives you a false sense of usefulness.