I and many others have done it for years. HTTP codes were not designed for the web in 2023. They were for the 90s.

Nothing has changed which would invalidate the basic model, though.

“It’s old” isn’t a reason to throw out a working design.

No, the reason is "It was built for a time when people expected the web to mostly be a series of interconnected static documents"

That still doesn’t explain any actual problem, it explains what you think is the cause behind the unspecified problem, jumping right over the key question.

Basically, HTTP is the envelope.

Ethernet > IP > TCP > HTTP > My application

HTTP is a hyper text transfer protocol, designed as such. My application is a RPC front-end for a series of data stores, AI models, etc.

Using HTTP codes for your application's protocol is a mismatch. There are some fairly general-purpose HTTP error codes that can meet many application's use cases, but the overlap is not perfect. You can get greater granularity by ignoring it entirely.

Going HTTP 200-only means any non-200 is now definitively from 3rd party middleware, a router, proxy, etc. The boolean check of "did I hit my application code?" is easy and useful.

Its easy and useful if you just return details in response bodies, which you can do with errors as well as 200s, and that lets everything else (including client code) that deals with your responses (which doesn’t generally care if it hit your application code as likely as it cares about the things HTTP error codes communicate) handle errors without having to code for your bespoke method of error reporting.