" Use searchable names" - I don't entirely agree that making code more complex the way they've shown is good. I use comments to ensure that code is comprehensible. That way, I can have compressed code for efficiency and readable code for development.
" Use default parameters instead of short circuiting or conditionals" - Not all environments properly support defaults I don't think - at least that's what ESLINT with ES Standard formatting seems to tell me. Perhaps more importantly, you have to take care to not have parameters without defaults after ones the do. This is not always feasible.
" Function arguments (2 or fewer ideally)" - while this is true, when a function evolves over time, it can be hard to avoid - not really an excuse but refactoring from many arguments to a single object argument, tracking down everywhere that uses the function and retesting everything can be a lot of work.
" Set default objects with Object.assign" - Ah! This is one we should use more often - however, noting that the example template node and therefore nearly all custom nodes do this the "bad" way - including mine! Added to my refactoring table in the roadmap.
Flags as fn args and avoiding side effects - yes well. In theory this looks good. In practice .... sometimes just easier to get things done, right? This is the kind of thing I tend to come back to. Personally, I believe that breaking the flow of creativity is worse than "getting it right according to the theory". This is especially true for someone like myself who isn't doing development as a day-job.
" Don't write to global functions" - Honestly - DON'T POLUTE ANYTHING! Seems like a good rule of life to me! Avoid the prototype
like the plague if you can. Tracking that stuff down is a nightmare.
Functional vs imperative - yes, well, another one of those "good in theory" things. I'm sure they are right - in theory.
Conditionals - life is too short!
Kind of gave up 1/2 way through - will re-read again at some point.
Don't get me wrong, a lot of these are "good" for sure and worth trying to get into your style - but not necessarily at the cost of getting things done.
Of course, you should also consider the environment you are working in. Is it commercial or personal? Is someone's life or business riding on your code? Or does it just mean that your house lighting does something odd?
The bigger and more critical/expensive the environment, the more you will want to pay attention to the more structural and theoretical elements described.
Of course, if you can learn it all and still write creatively in good time - well, you should be getting well paid. Because you will deserve it