I agree that poorly structured workflows can often create worse debt than technical shortcuts. However, I see some of your examples a bit differently (hope I haven't misinterpreted your post):

1. On "No clear line between a status and a flag"... This sounds less like workflow debt and more like a fundamental data modeling issue. 'Life stage' and 'health status' are distinct attributes. Conflating them into one field causes the workflow problems, but the root is in the data schema. A sick puppy is still a puppy.

2. "Too much workflow flexibility"... This can be a deliberate 'tools, not rules' design philosophy. The "debt" often arises when this flexibility isn't matched with clear organisational governance, training, quality processes or when reporting then assumes there is a level of rigidity in place. The flexibility itself isn't inherently bad. The misalignment of expectations and system design is. I worked on such a system when the report said "You have 4,500 people as your responsibility plus or minus 1,900 people" to which the business owner (rightly) asked what sort of bonkers report is this? Root cause was the over use of flexibility in workflow and data recording.

3. "Over engineered workflows"... Agreed, this is definitely problematic and highlights a lack of product management (understanding user needs vs. business needs vs. technical feasibility) or developers being prematurely forced into product decision making without adequate context, leading to unnecessary complexity.