The Jupyter and IPython projects have been around more than 10 years and a lot has changed over the years in terms of frontend development: V8, Node, npm, transpilers, JS Compilers, competing module loading systems, auto-updating browsers, new frameworks, and many other bits. They've all come and made front end development much better. At the same time, they've bred complexity in choice and decisions. Some of the biggest warts have been the document API for the DOM, how we work on it, the tendency to get addicted to the ease of jQuery, and the resulting jQuery soup that gets created. Large projects have to make a choice on how they're going to package and ship components of their overall application.
There was a time at which I was comfortable in CoffeeScript. Now that I've read JavaScript the Good Parts, Node.js the Right Way, read and written more JavaScript, listened to and worked with people in the JS/Node/iojs community, I'm NEVER going back to an X->JS language that isn't JavaScript proper (yes this means I'm fine with babel, 6to5, traceur, etc.). Prototypal inheritance is neat and ES6 classes are quite wonderful too!
As an open source project, we should choose the JavaScript dialect that is most common and prolific. Jupyter is a community driven open source project. By not choosing the dominant language, we've limited the number of possible contributors.
Writing good JavaScript is available to you. JavaScript is ubiquitous and useful. Adopting the node way of writing simple modules is fundamentally a Good Thing™. Figuring out where those dividing lines are is difficult, but nothing is stopping us from breaking things up where we see fit and using the already HUMONGOUS amount of packages available on npm. In addition, testing and working with JSDom is quite wonderful. Extending out to test with other browsers with karma is right at our fingertips as well.
My stance, right now, is that we should be packaging JavaScript as node packages under the commonjs standard. If people want that bundled differently, there are tools for that. This is not some crazy thing. People have been at this for a while. I'm using node packages in the frontend right now. Don't equate node packages as meaning that they have to run in node. It makes development easier. By relying on available packages and creating our own, we don't have to invent out of whole cloth, the entire ecosystem of tools we need for rich applications that consume the super-rich Jupyter Message Protocol, the notebook format, and any other language agnostic enablers of good we create.
This shouldn't be taken to mean that people should conform with only ES6 (or ES5) for that matter. If they're happy in (Type|Coffee)Script, it makes their team more productive, and encourages the right kinds of contributors, then by all means - do it. Just make sure that your code is usable under the JavaScript Universe.