Having a useful error message in all cases requires understanding all possible error conditions in sufficient detail (vs a catch all). Most system don’t have a clear enough grasp of all possible error conditions.
This is the root of the problem, I think. Especially in JavaScript with the blanket ‘catch’ mechanism and no real good way to have any idea of what exceptions could have even been thrown in the current context.
Obviously the dev will have some idea of which error could have occurred (hence the use of ‘catch’ at all), but it’s not straightforward to enumerate all possible exceptions in that moment, and reason about some subset that should be human-readable, and then come up with some sort of instructions about how to fix the problem.
Maybe that’s the point of the root comment - the exceptions that the dev is trying to catch and prevent from affecting the user should have those human-readable descriptions. And the rest should be silently logged?
But that still just leads to the generic “Well, this is awkward…” errors that you see these days.
It’s a tough topic, and even having the insight of (for example) Java’s ‘throws’ still doesn’t mean the developer explicitly understands the state of the application when those exceptions are thrown (in order to provide some sort of useful message to the user).
I believe software should explain itself to the user. Even if the user may not understand.
If you feel uncomfortable telling the User What you're doing, and Why you're doing it, you probably Shouldn't Be Writing It!
If everyone did as much, there'd be entire classes of software (and the ethical bad juju that comes therewith) that wouldn't have been written.