Comment by HelloNurse

There's a word, in other comments, that I expected to find: zealots. Zealots aren't sufficiently critical, and they don't want to think for themselves; a reasonable person should be able to, and a professional should be constantly itching to, step back, look at code, and decide whether some refactoring or rewriting is an improvement, taking a book like Clean Code as a source of general principles and good examples, not of rules.

All the "bad" examples discussed in the article are rather context dependent, representing uninspired examples or extreme tastes in the book rather than bad or obsolete ideas.

Shredding medium length meaningful operations into many very small and quite ad hoc functions can reduce redundancy at the expense of readability, which might or might not be an improvement; a little DSL that looks silly if used in a couple of test cases can be readable and efficient if more extensive usage makes it familiar; a function with boolean arguments can be an accretion of special cases, mature for refactoring or a respectable way to organize otherwise repetitive code.