That's a rather binary view and I disagree that rules always fall in either category.
Knowing _why_ a rule exists and what it's trying to prevent/achieve is much more valuable in my opinion. Wether or not to follow or bend a rule depends so much on the context.
I think it's a worthwhile addition to highlight there is 3) rules which are sometimes red tape and sometimes to be broken, on top of the other 2 categories. It adds on to the original point with the addition of how to universally discover what the categories are rather than prescribe them up front.
To add to that, #3 is often explicitly encoded into the red tape as an escape hatch for foreseeable exceptional circumstances like disaster recovery and big client emergencies.
Knowing _why_ a rule exists and what it's trying to prevent/achieve is much more valuable in my opinion. Wether or not to follow or bend a rule depends so much on the context.