Thank you! That's a great point and it's actually something we considered adding as a dedicated section, though the post was already running long.

Industry context does change the calculus significantly. Healthcare is a good example: if you're working with FHIR, the specification already defines its own error format (OperationOutcome), so Problem Details effectively gives way to the domain standard in that context.

Fintech is another case worth noting. Those teams typically adopt Problem Details but rely heavily on its extension fields, largely because audit and traceability requirements demand machine-readable error codes that align with regulatory expectations.

High-traffic domains like retail, on the other hand, tend to favor the minimal HTTP-semantic approach, since CDN-level caching delivers meaningful cost savings and an envelope tends to work against that.

The decision framework still applies in each case. It's the weighting of the criteria that shifts depending on what you're building. The one constant across every industry is that the "200 OK with success: false" pattern should always be avoided.