The only thing I'm missing there is the filename, otherwise this is a helpful error message since it tells the user what the problem is and at which stage the error occurred. Stack traces, on the other hand, are mostly only helpful to the original developer(s) of a program, they won't help most ordinary users. And while they of course include the calling context they usually don't include other crucial information like variables (e.g. the filename in the example above).
Also, raising and catching exceptions is expensive in many languages. I know that in Java it's fast, but other languages like Python produce significant overhead when creating and raising an exception, that's something one should consider as well.
All you're arguing, then, is that regardless of whether you use error values or exceptions, you need to write good error messages. Hmm, okay. I agree with you on that. But I don't see how that counts against exceptions. Do you think the error message of an exception cannot contain filenames and variable values? And even in cases where they don't (e.g. you're depending on an external library with poor error messages), do you think it's impossible to add context to an exception's error message after it's been raised?
Also, the performance argument counts against your point, not for it. Exceptions rarely happen (when used properly), and when they are not raised, they cost nothing. Whereas go-style errors require explicit checks every single time you execute an operation which can fail.
Also, raising and catching exceptions is expensive in many languages. I know that in Java it's fast, but other languages like Python produce significant overhead when creating and raising an exception, that's something one should consider as well.