You need to add more actual reasons or examples when a http status code while good for application error would generate failures for routing and caching and proxies.
Here is a reverse one:
say you have an URL that has a slug: maybe it contains the week of the year like
/weeks/38
and you delete that from the app and now you say the /weeks/38 will return 200 => so all defaul caches will cache that response.
now you go back and decide ahh I actually want that week so you recreate it => well if you dont configure the in front of the api caching it will return you the previous response 200+whatever error code you had.
while in case of 404 the majority of cache services I put in front of any API will by default allow bypass of cache in case of 404 and cache response by default in case of 200.
Here is a reverse one: say you have an URL that has a slug: maybe it contains the week of the year like /weeks/38
and you delete that from the app and now you say the /weeks/38 will return 200 => so all defaul caches will cache that response. now you go back and decide ahh I actually want that week so you recreate it => well if you dont configure the in front of the api caching it will return you the previous response 200+whatever error code you had.
while in case of 404 the majority of cache services I put in front of any API will by default allow bypass of cache in case of 404 and cache response by default in case of 200.