HTTP is the only protocol that's supported by browsers. I don't need hypertext in my APIs. I want RPC in my APIs. But browsers force me to use HTTP. So don't complain if my RPC APIs don't fit into the whole REST philosophy, as I don't care about philosophy, I'm engineer and I care about technical arguments. For all I care HTTP is a message protocol with headers to carry some attributes and some bytes in payload. For all I care, between client and server could be some proxies which can cache something (and thanks to HTTPS, I can be sure that all proxies are controlled by me). For all I care, between client and server could be some analytics software which will analyze traffic and might mark node as unhealthy based on 5xx HTTP codes or something like that. That's technical arguments and I do consider it.

Spending time arguing whether 400 or 404 or 422 is better fit is not engineering. You must return exact sting error code and that's about it. Whether that string error code wrapped in 400, 404 or 422 error does not matter. I, personally, use 400 errors everywhere because they're unlikely to occur from misconfigured reverse proxies and they won't confuse my clients which treat everything that's not 400 as gateway error. I think that I should start using HTTP 202 for all successful responses as well.