The point GP was making is that both Go and Java (in code which makes heavy use of checked exceptions and different exception types) mix together the business logic with error propagation. So, even though in Java you throw exceptions and in Go you return error values, they both end up (or can end up, in the case of Java) having lots of error handling boilerplate all around a function.

In Java of course this doesn't have to happen, but it can end up happening if you chose to have many exception types and different exceptions types when crossing layers (e.g. try { doX(); } catch (IOException e) { throw new MiddleLayerException("failed to do X", e);}).

To be fair though, Java still allows you to write that like this:

  try{ 
    x = doX();
    y = doY(x);
    z = doZ(y);
  } catch (XException | YException | ZException e) {
    throw new MiddleLayerException("...", e);
  }

Which is still better than Go's:

  x, err := doX();
  if err != nil {
    return MiddleLayerErr(err);
  }
  y, err := doY();
  if err != nil {
    return MiddleLayerErr(err);
  }
  z, err := doZ();
  if err != nil { 
    return MiddleLayerErr(err);
  }