Some bad design advice

The thing I hate about advice like this¹ is the fact that if I follow this approach, I have the problem that if I later switch to another transport, I suddenly am missing the status code (even if this other transport is something web affiliated like websockets and not something native like ZeroMQ). Adding the status code to the payload in the first place makes my message handling transport agnostic. Even if I don't have an alternative transport in practice (the common case, to be honest), this also affects testing: if I use the HTTP status code, I cannot do pure payload testing, but have to have a stub HTTP server running.

Edit 2023-04-26:
Another piece of bad advice is the old "make invalid states unrepresentable" trope (exemplified here: ², but I realize that this is not the point of this particular post at all, it's just the latest I came across that tangentially mentions it). From a rational, superficial standpoint, "make invalid states unrepresentable" sounds good. The trouble starts when you need to pass the info about why your domain model is invalid back to the layers that use it, and the specific data that makes it invalid. Just returning an empty optional³ back is hostile to the user of the API. For the specific case discussed, I would design the domain model such that the validation state is a (bitfield usable, i.e. ORable) enum VALIDATION_STATE_OK, VALIDATION_STATE_INVALID_LUHN etc. If there's a need to really make sure that invalid cases are not used where valid cases are expected, do a dummy derivation ValidCard that will only be returned from the happy path, but is structurally identical to the base class.