I'm deeply aware of how unpopular some of the rules in this coding standard would be to many. It's okay, I still like you, and I hope the same from you! ;) You may take solace in the fact that over time as less-structured programming has become popular, I've had to follow "your" coding standards! In my view, as supply-and-demand evens out, we'll see a return to the efficiencies one can obtain from following the kinds of rules in my coding standard.
When I read a coding standard, I often wonder why the authors stated certain rules and wished they would provide a little context, so that I could understand the rules themselves better. It's more practical if a succinct statement of the "why" is provided alongside a given rule itself. I've included brief descriptions of the reasons for certain rules in the coding standard where I thought it was appropriate.
And even use of 'eval' only can be dangerous if the input is untrusted, which means that the true security failure lies elsewhere. That's not to say it might be better to avoid 'eval', but it's a rather lengthy discussion that I thought would fit better elsewhere. By contrast, defending 'parseInt' is very straightforward and could eliminate many unintentional errors, so that is included.