People coming from a history of pretty much just client-side programming (or moving to JS server-side from completely different languages, having worked with JS client-side) might just use eval because that is what they've done before (not knowing that JSON.parse exists). The nodejs documents don't explicitly list JSON as part of its API (because it isn't, it is part of V8's codebase) so an inexperienced programmer using the node documents as a base for tinkering might not discover the built-in JSON parser early on so use eval instead.
Admittedly you should not be using eval() client side either for much the same reasons you chould not be using it server-side, instead find a decent JSON library and use it's parse(). Modern browsers include such utility functions anyway, but you can't rely on them if you need to remain compatible with old-but-still-common junk like IE6/7/8.
"you should not be using eval() client side either for much the same reasons you should not be using it server-side"
Can you explain this? I'd think on the server side you'd do it because you should never trust client input. On the client side, though, presumably you can trust the input from your own server.
I recognize things can get a bit trickier when you have scripts from untrusted sources mingling with yours in the same page, but at that point, given the dynamic nature of JavaScript and the way behavior attached to DOM elements can be wrapped/changed, I'm not sure eval vs JSON.parse is really your biggest problem, and I could totally see someone who knew about JSON.parse going with eval on the client side using that line of reasoning.
"I recognize things can get a bit trickier when you have scripts from untrusted sources mingling with yours in the same page"
Well, that's it exactly. Today's trivial unexploitable vulnerability gets combined with tomorrow's trivial unexploitable vulnerability and viola arbitrary command execution as the web server user. Or whatever. There's no vulnerability too trivial to fix, because in reality you can never be sure that a given vulnerability is unexploitable today, or will remain unexploitable tomorrow.
Used client-side you are still exposing yourself to cross-site security issues and the like. While you are right that the client-side JS environment is prone to this by other methods, this doesn't mean you shoud open up this method too.
I've seen it used by beginners (espectially those who don't consider themselves beginners!) who are not particularly security concious yet. Books and tutorials cover it then say "but don't use it unles you really really have to becase ...": people remeber what it does but not the warnings that were attached.
I think it needs to not be covered at all for the most part in documentation that might be used by a beginner, in any language not just Javascipt, rather than telling people about it then telling them not to use it.
It gets used because it is sometimes easier than the alternatives. If people don't know about eval() until they have learned enough to be capable of understanding the alternatives and the security implications of eval() then like us they'll do their level best to never use it.
eval() is commonly understood to be among the most evil commands you can invoke when programming, and you'd better have a damn good reason for why you're using it, and why something else isn't appropriate. This is hardly esoteric knowledge.
The first rule of application programming is "don't trust user input". eval() requires that the eval'd string be trusted to avoid security holes. The two are mutually exclusive.
In the NodeJS case, this is probably a case of misinformation. If people are teaching the use of unchecked eval, then that's a pretty huge problem. I'd be very interested to see examples in the wild of this happening, though, as it seems like such an obvious mistake that most anyone trying to teach would know to avoid it.
Admittedly you should not be using eval() client side either for much the same reasons you chould not be using it server-side, instead find a decent JSON library and use it's parse(). Modern browsers include such utility functions anyway, but you can't rely on them if you need to remain compatible with old-but-still-common junk like IE6/7/8.