Some people treat http as a pure transport/network layer and the actual body as the app-level layer.

In such an approach, any http-level error would be a network, server maintenance or other unknown/fatal error type of things.

App errors are encoded in the response body in a app-defined way.

It's not a completely bogus way of handling things, as long as it is perfectly consistent throughout the project and properly documented, which is rarely the case.

Looks pointedly at graphQL projects.

The opposite of that is people who try to loosely project the variety of error modes their app has to http status codes. You then print out a table of http code <-> actual meaning and try to outline ranges and messages you want to handle differently. On top of that, their backend may be down and you have to deal with bare reverse proxy statuses as well, which adds another dimension to that mess.