E.g. you hit an exception that should have never popped up. Does it read badly? Oh well of course it does, because nobody who could have written it more clearly knew it was even possible to pop up in this instance. He might have even tested your scenario, but his system package xyz wasn't in version 13.4.12 as yours, but in 13.4.12b, so in his context it worked. You can minimize these things, but you can't completely make them go away. Even make them go away most of the time is often too expensive. You can of course also choose to invest $500k every year into Babel to increase their testing, but I certainly wouldn't, just to make a few exceptions more readable.
And in fact, if you tracked down from all the context variables why it failed in your context, you will actually find out that you can track down the change to an issue and a developer and you can discuss with them how in that case a better exception can be printed, how the code may need to be changed to consider the context you are providing etc.
Nothing of this is done better when reading usability guidelines. Just as well as you and me people mostly know what is good and what is bad. They don't need teaching in that.
The thing that can be really done is always try harder in your code (when was the last time you looked into the docs/source of a lib function you use and catch the exceptions that function can throw, handle some of them and raise more readable exceptions for the once you can't handle?). Secondly, when you hit such a situation you can spend the time to track down the error to its core, write a good issue about it, discuss with the responsible devs what to do and help implement the solution (have you looked at the underlying library functions, caught their exceptions... oh, you know what I mean, right? People often don't do that part). Last but not least when one has done that often enough to be good at it, to spend time and energy to help some noobs to do the same (and teach them how to read the underlying library functions).