Naming conflicts aren't all that hard to resolve with a little forethought; if you're concerned about them, as you should be if you're thinking about extending prototypes in a codebase with which you're not intimately familiar, fire up your REPL and see what it returns for the name of the prototype extension you're thinking about adding. (If it's already there, that's one function you didn't have to write!)
As for the enumeration example, you're not making a point about extending the environment in general, but only about extending it wrong -- that is, by simply assigning functions to prototype slots, rather than using Object.defineProperty to do it right.
There are arguments to be made for writing style guides and programmer's cheatsheets with a half-competent audience in mind. All of those arguments are bad ones. The linked guide is generally reasonable, but I'd be a lot happier with it if it said "extending prototypes is usually a bad idea, but if you have to do it, here's how to stay off the landmines", rather than a superficially snicker-worthy insult to the reader such as "don't do this or you'll go to hell".
As for the enumeration example, you're not making a point about extending the environment in general, but only about extending it wrong -- that is, by simply assigning functions to prototype slots, rather than using Object.defineProperty to do it right.
There are arguments to be made for writing style guides and programmer's cheatsheets with a half-competent audience in mind. All of those arguments are bad ones. The linked guide is generally reasonable, but I'd be a lot happier with it if it said "extending prototypes is usually a bad idea, but if you have to do it, here's how to stay off the landmines", rather than a superficially snicker-worthy insult to the reader such as "don't do this or you'll go to hell".