However thats not the case. The author has distilled lots of experience into something reasonably readable.
e.g. a user is enabled if they have paid... time passes... now a user is enabled if the team they belong to has paid. now you need to move the logic to another struct / class and the data to another table.
now this is where "payables" and things come in and you start going the path of clean code with 1000 classes.
instead, the best way to do this is immutable data streams and event listeners.
after over a decade of programming, i feel for most software with a customer focus (not low level, embedded etc), immutable data streams where data flows through and listeners do things to themselves is the best way.
Principles arent universal across technologies
Hell, principles arent even universal across software kind (e.g goto arent used in C# web dev, but std lib? yes)
Like, this is a conversation Uncle Bob had with Casey Muratori on GitHub, I came away feeling like Uncle Bob is more interested in playing rhetorical judo than anything else: https://github.com/unclebob/cmuratori-discussion/blob/main/c...
Premature optimization is the root of all evil. (Donald Knuth)
Personally, my biggest gripe comes from experiencing people trying to introduce it to a team. Inevitably someone tries to enthusiastically implement some part of it and suddenly are writing 1 line functions everywhere. I think this is the type of thing Casey is also implicitly talking about when he's railing against the rules being brought up.
[1] https://www.youtube.com/watch?v=rX0ItVEVjHc