That may be your opinion, but the spec is clear:

6.6

[...] Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation[...].

"SHOULD" has a very specific meaning in RFCs. Contrast to "MUST".

Unless the user can fix the problem, and you want them to try, an explanation of a 5xx error adds no value. Again, I don't think 5xx is ever a valid response from an API -- it's always a server-side error (code or infrastructure) that needs fixing, often with high priority.

In many environments (e.g. medical, financial, or other secure/private), providing details on server errors is strongly discouraged. Even when the data isn't sensitive, I think you're asking for trouble by broadcasting server-side problem details to users.

Fair enough. You've convinced me on this - especially on the 5xx I think it's a very good point that a description of the error could potentially have undesirable consequences.

I think my original point stands though, that status codes do tell you about the body in some circumstances. Or SHOULD tell you something about the body at least :)

SHOULD is not MUST [0], and “The user can do nothing about the problem and is likely to experience negative utility from any attempt to provide more detail than what the status code provides” is arguably a valid reason not to send a body with 5xx status responses.

[0] https://www.rfc-editor.org/rfc/rfc2119.html

Per my response to OP, I've been convinced on this.