The point is historical preservation: Putting ancient games and systems on the Web as a way to enable people to experience them, as part of digital museums, online academic papers, and such, to provide some (imperfect) context for what would otherwise be dry technical history. It's in JS because it's the only language that doesn't require plugins, and so has a better-than-average chance of running on a variety of different hardware.
But why use a deliberately slow emulator as a base for all of this? Is accuracy really that important when compared to being able to run it on a wide variety of hardware? Why not just bundle some existing JS emulators together or take some fast native emulators and do the emscripten thing?
The two are not competing goals. There are plenty of emulators that aim for speed, so it makes perfect sense for someone to want to focus on accuracy. And yes, it is that important if your goal is to actually preserve things properly.
I don't know about the NES as I never had one, but on the C64 for example, a single cycle deviation in the emulation of interaction between the CPU, graphics chip and memory bus would make some effects impossible to reproduce. And similarly on the C64, people are still struggling to make the SID (sound) chip emulation as accurate as possible, as it used a combination of analogue filters that have proven extremely hard to accurately reproduce in emulation.
People casually testing these games might not care, but many of those of us who used these systems notice these flaws and appreciate that not all of the emulation projects focus only on speed.
Because it's fast enough or close to it now and this should only improve over time: it's often much harder to improve accuracy depending on the shortcuts made for performance.
http://jsmess.textfiles.com
http://ascii.textfiles.com/archives/3745
http://archiveteam.org/index.php?title=Javascript_Mess