The Error Already Told You
Vim's readonly error is three lines shorter than it needs to be and better for it: E45: 'readonly' option is set (add ! to override). No paragraph about file permissions, no explanation of why the buffer got marked that way. Just the syntax you need, sitting right there, almost ready to paste back into the command line.
Compare that to the kind of error that spends four sentences establishing context before it gets to the point, if it gets to the point at all. A stack trace that tells you the call chain but not the fix. A dialog box that explains what went wrong in full paragraph form and leaves the actual remedy as an exercise for the reader. These feel more thorough. They are not more useful, because they're answering a question nobody asked in that moment.
When an error interrupts you, you are not trying to build a mental model of the system. You are trying to get back to the thing you were doing before the system stopped you. The question in your head isn't "why" -- it's "what do I type now." A message that explains the cause is optimizing for a reader who wants to understand. A message that states the fix is optimizing for a reader who wants to act. Those are different jobs, and almost every error message is written for the first reader while almost every actual reader, in the actual moment, is the second one.
The tell is what people do when they hit a wall of explanation instead of an instruction: they skip it. They go shell out and retype the save command, or they close the dialog and try the thing again, or they paste the whole block into a search engine rather than read the sentence sitting in front of them. That's not laziness so much as a reasonable triage. If the message reads like documentation, it gets treated like documentation -- something to consult later, not something that's already answered the question. Information gets filed as an obstacle to route around rather than the resolution itself, and the instinct isn't wrong often enough to get corrected.
What's actually asymmetric here is who pays the cost of understanding. A causal explanation pushes the work of figuring out what to do onto the reader, at the worst possible time to ask them to do it. An imperative message means the author already did that work, already decided what the fix is, and handed it over pre-chewed. Writing the second kind is harder, not easier -- you have to know your own system well enough to collapse "here's what went wrong" into "here's what to type," and most error-message code is written in the five minutes after the exception is caught, by someone who hasn't thought that far ahead. Verbose is often just unfinished.
None of this means causes don't matter. It means they belong somewhere other than the interrupt. Log the cause, surface it on request, put it in the docs the error links to. But the line that appears at the moment of failure has one job, and it's not to teach you something. It's to get you unstuck, in language you could paste back in without thinking.