My point is that you don't have to design the whole type chain ahead of time, you can discover new type constraints as you go and apply them straight away (in the same way that you don't have to wait until you finish your design to start writing unit tests).
Maybe an experienced game programmer would notice straight away that it could be a problem to draw a state that has not undergone collision detection, and design this state constraint into the game straight away (as a type, as an assert, etc.) and maybe another programmer wouldn't notice this requirement until they ran the game and noticed something odd (or someone from QA notified them) and had to dig through the system to find the underlying reason. But once they shot themselves in the foot once, it makes sense to implement _something_ to detect when they make the same mistake again.
During the design stage, you do need working components, independently implemented, and experiment various combinations. If you use types, that means frequently rewriting types to match the reorganizations of control flow. Types still help to prevent mistakes, but the main part of actual design process (like working on clay, or, scrap & rebuild with Lego pieces) is just as tedious as other ways. I read that the original article is trying to address that problem.
Maybe an experienced game programmer would notice straight away that it could be a problem to draw a state that has not undergone collision detection, and design this state constraint into the game straight away (as a type, as an assert, etc.) and maybe another programmer wouldn't notice this requirement until they ran the game and noticed something odd (or someone from QA notified them) and had to dig through the system to find the underlying reason. But once they shot themselves in the foot once, it makes sense to implement _something_ to detect when they make the same mistake again.