You only have 20 options, but making that many distinctive options is not exactly a stretch. It's not like every single set of options is its own code path, most options represents a small deviation at one particular part of the code. Most of the options aren't mutually exclusive either, only a few combinations are illegal.

Imagine a simple shipping system for example. The package might be routed via truck, boat, plane, pipeline, foot, etc... Probably even a combination of those options. The package might be low, medium, or high priority, although high priority packages are not allowed to be delivered by boat. The package might be small, large, or liquid, but liquids can't be delivered by foot. There are 195 different countries with even more regulatory regimes to consider, some of which may have different customs requirements based on mode of transport. Now imagine a problem that is actually complicated.

The idea of encoding all of this business logic into the datatype is a road to madness IMHO. Especially if the rules can change on you and require you to rework your datatypes to match. On the small scale this makes a lot of sense and is good advice, but strict adherence is impractical.

You don't need a single type to represent the entire program state.

We probably both agree that separate types for shipping methods, priorities, size, country makes sense.

The API can be designed to prevent illegal transitions between types to arrive at an invalid state. The exact implementation depends on the language.

> The idea of encoding all of this business logic into the datatype is a road to madness IMHO

The alternative is hoping that every developer remembers not to violate any of the implicit and unenforced rules.

If the system is too complicated to be represented in code, can a human realistically hold the entire state machine in their head as they make changes?