I really feel that too many rules like this lead beginners astray and focus on issues that make very little difference in delivering a product.
If beginners see a list like this, and start re-factoring the code to remove "Boolean blindness", that's likely not the best way for them to spend their time and the code may become more verbose in the process.
I prefer not to dwell on negativity about code, as long as it does the job and is implemented in a reasonably simple manner. I think in the Haskell community sometimes there can be an unhealthy tendency to nitpick the implementation details.
I wouldn't consider them rules inasmuch as they're things to keep in mind when working in a Haskell codebase, in much the same way GoF has been useful for OO programmers for decades.
Can you write code without using a pattern from GoF? Sure. Will it work? Probably. Does that make GoF useless? No, I'd think not. This type of content is immensely valuable for beginner and practitioner alike because it starts to build a shared language with which to talk about how codebases are organized :)
As a beginner you're just trying to keep your head above water and get the damn thing to compile. For me at least I cared more about that than making the code pretty.
Moreover I don't see much harm refactoring your code with these patterns and maybe losing time, because most people learn haskell off the job.
