My perfunctory reading is thus: first you couple your state representation to the business logic, and make some states unrepresentable (say every client is category A, B or C). Maybe you allow yourself some flexibility, like you can add more client types.
Then the business people come and tell you some new client is both A and B, and maybe Z as well, quickly now, type type type.
And that there's a tradeoff between:
- eliminating invalid states, leading to less errors, and
- inflexibility in changes to the business logic down the way.
Maybe I misunderstood, but if this is right, then it's a good point. And I would add: when modelling some business logic, ask yourself how likely it is to change. If it's something pretty concrete and immovable, feel free to make the representation rigid. But if not, and even if the business people insist otherwise, look for ways to retain flexibility down the line, even if it means some invalid states are indeed representable in code.