I found out due to a live bug that Apache strips out the response body for 5xx HTTP codes for security, and it's not configurable, so you can't use any of those if you want to return the error message to the user. Don't know what else might do the same, so nowadays I only use HTTP error codes for protocol-level issues, and application-level issues all go into a 200 OK with JSON just like that.
I'm pretty sure it was all 5xx but can't remember for certain. This was back in 2019, with a much older project, and I'm pretty sure that part of the code was the same as of 2019.
It comes from ap_send_error_response(), near the bottom starting at https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d...
Scrolling up from there a bit you can see some of the handling for ErrorDocument, which is configurable ( https://httpd.apache.org/docs/current/custom-error.html ) but also loses the original response body.
ap_send_error_response() is only called from the last line of ap_die_r() ( https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d... ), as the fallback for errors when none of the other conditions pass. There's some other handling for redirects and custom ErrorDocument, but again, if it reaches those it's using the contents of "custom_response" instead of the original response body.
ap_die_r() is called unconditionally for completed requests ( https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d... ), which is why api_die_r() starts with an early return for an OK or DONE response. Its wrapper ap_die() is also used in plenty of other locations as a general error handler.
It's been a while so I had to go through it again, the code isn't exactly what I'm half remembering, but I do remember the "assbackwards" lines in ap_send_error_response() ( https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d... and https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d... ). If the particular check I think I remember did exist (explicit status codes in an "if", similar to your earlier link), it was probably in the even older version we were using. The early return I'm pretty sure wasn't there (blame puts it at 12 years old), so all responses would have gone through more of the error handling code back then.
Edit: Replacing "trunk" branch with most recent commit so line numbers continue to work in the future
Truly "application level" issues are therefore correct as 200, although some application communication issues lead to 4xx errors that should be handled as such. But the case of an application trying to communicate via 5xx errors should never have been the case anyway.