Programming

This guy backends ☝️

but often lead developers to just display them in the frontend

Oh boy I feel this one.
My API is meant for scripting (i.e. it's for developers and the errors are for developers), but the UI team uses it and they just straight display the error from their HTTP request for none technical people which might also not get to know all the parameters actually needed for the request.
And even when the error is in fact in my code, and I sent all the data I need to debug and replicate the error, the users can't tell me because the UI truncates the response, so the user only sees something like Error in pe1uca's API: {"error":"bad request","message":"Your request has an error, please check th... (truncated). So the message gets truncated and the link to the documentation is also never shown .-.

To be fair if it's an exceptional error message (i.e. database timeout; not incorrect password) I don't think i18n matters that much. Most people will just be googling the error message anyway, and if not it should be rare enough that using Google translate isn't an issue.

This is the right answer imo. While it might be an overkill for sth like 404s, it's amazing for describing different bad requests.

This one looks nice. Very detailed.

I worked on a product that was only allowed to return 200 OK, no matter what.

Apparently some early and wealthy customer was too lazy to check error codes in the response, so we had to return 200 or else their site broke. Then we'd get emails from other customers complaining that our response codes were wrong.

I don't necessarily disagree, but I have spent considerable time on this subject and can see merit in decoupling your own error signaling from the HTTP layer.

No matter how you design your API, if you're passing through additional layers, like load balancers and CDNs, you no longer have full control over all responses your clients receive. At this point it may be viable to always signal a successful backend connection with a 200, even if the process resulted in a failure.

Going further, your API may include partial success scenarios, think batch processing, then the result could be a mix of success and failure that doesn't translate to HTTP status.

You could even argue that there is really no reason to couple your API so tightly with a concept of the transport layer it uses.

I use this big expensive simulator called Questa, and if there's an error during the simulation it prints Errors: 1, Warnings: 0 and then exits with EXIT_SUCCESS (0)! I tried to convince them that this is wrong but they're like "but it successfully simulated the error". 🤦🏻‍♂️

We end up parsing the output which is very dumb but also seems to be industry standard in the silicon industry unfortunately (hardware people are not very good at software engineering).

That really is unholy and I also couldn't work there long if they thought that was OK (pun intended).

I would actually encourage error responses be in JSON if your 200 responses are JSON. Some clients are apt to always convert the body to JSON so it could avoid an exception on the client side not to throw a curveball.

To your point it's most important that the content and Content-Type header match.

I have worked for financial institutions that have variations of the last one. If I saw it I wouldn't even blink. Semi realistic reasons might be:

Status attribute - because the project is using the base library of [project whatever] which was the brain child of eNtErPrIsE aRcHiTeCt whose hands on skills are useless and the off-shore dev team who assigned [random newbie] because that's who was available at the time. They used a status attribute because they didn't know how to get the status of the http response. No-one with budget control is interested in hearing about technical debt at the moment. Everyone has to use it now else the poorly written test classes fail.

Message code: because "we need codes that won't ever change even if the message does". Bonus points if this is, in fact, never used as intended and changes more frequently than...

Message: "because we still need to put something human readable in the log". Bonus points x2 if this is localised to the location of the server rather than the locale of the request. Bonus x3 if this is what subsequent business logic is built on leading to obscure errors when the service is moved from AWS East Virginia to AWS London (requests to London returning "colour" instead of "color" break [pick any service you never thought would get broken by this]).

I have seen it all etc

There may be a need for additional information, there just isn't any in these responses. Using a basic JSON schema like the Problem Details RFC provides a standard way to add that information if necessary. Error codes are also often too general to have an application specific meaning. For example, is a "400 bad request" response caused by a malformed payload, a syntactically valid but semantically invalid payload, or what? Hence you put some data in the response body.