That's really only a problem if you're contributing to the core, right? You can write your own packages in JS, and if you're just a user of the editor I don't see how that matters.
Sure, you can write your own packages in vanilla JS. Unfortunately though all of the documentation (and most packages themselves) are all written in coffeescript. Basically, the only way you can write a plugin in Javascript is if you already know Coffeescript (at least enough to read it).
It's just one extra barrier of entry for non-coffeescript developers. I personally thought about writing a simple plugin, went to the documentation and realized it was all in coffeescript with no JS option, and gave up. I simply don't have the mental capacity to learn another language that probably won't be around in 10 years.
I wouldn't even classify CoffeeScript as another language. It's really just javascript with some syntactical sugar. It took me about 20 mins to get comfortable with it.
It's another barrier to entry. Documentation is probably the worst place to encounter a new language, since the reader is already confused and frustrated.
CoffeeScript is a nice language, but I think it's reputation suffers from it's association with Ruby. Far too many CoffeeScript tutorials are aimed at Rails devs who don't want to learn new syntax.
It's a lot of syntactic sugar and things removed. Even the ?: operator which I use a lot. Typing "a = if b then c else d" is a huge wasted opportunity to just keep the ?: op. Plus there's no way to get the == operator even if you know you want it and understand the nuances.
Sure, but it's not the same, on one side I'd like to read the core and hack it on my own terms, on the other I'd feel more comfortable writing packages if I could just read the core and see how things work under the hood. I'd like it to be a "hackable editor" as it touts itself, but as it stands right now it's a "hackable editor if you are comfortable with CoffeeScript".
CoffeeScript was released in a time when ES6 wasn't yet a thing as far as most developers were concerned. It was also a time when JS saw a huge influx of new developers coming from other languages. CoffeeScript itself draws heavily from Ruby (and some Python), which explains why it was rapidly adopted by the Ruby community and became part of Rails (just like Sass replaced CSS).
When I first revisited JavaScript after a long time writing Python code, I was quite fond of CoffeeScript because it let you pretend you're not actually writing JavaScript and because it enabled a lot of idioms that didn't exist in vanilla JavaScript.
CoffeeScript is decidedly not an extension of JavaScript. It doesn't build on existing JavaScript idioms and just add syntactic sugar (partially because many idioms of modern JS simply didn't exist at the time and there was less consensus about them) -- it substitutes idioms from Ruby and Python and implements their syntax, all the way down to changing how variables are declared and how the equality operator behaves.
CoffeeScript is written for programmers who understand JavaScript but don't want to write JavaScript when creating JavaScript code.
Thanks to Babel.js ES6 (now ES2015) is now a thing. Most of the new things CoffeeScript brought to the table for JavaScript programmers are now satisfied by the language itself or syntactic extensions supported by Babel. There is a well-understood and well-defined class syntax, there are arrow functions and tons of syntactic shorthands like method literals and object/array destructuring. What's more, because these are now officially part of the language, Babel itself just serves as a stopgap while we wait for the JS environments to catch up.
Outside its original use case of allowing Ruby programmers to avoid writing JavaScript, CoffeeScript is obsolete and (at least in terms of hype and momentum) dead. It has outserved its usefulness and has given way to more specialised languages (e.g. ClojureScript) and Babel.
It's unsurprising that Atom core is written in CoffeeScript if you consider that GitHub is and always was predominantly not a JavaScript company but a Ruby company. It is heavily invested in the Ruby world and CoffeeScript is part of the Ruby world more than it is part of the JavaScript world.
I'm not sure whether CoffeeScript's role in the Ruby world will change anytime soon, but outside that microcosm, it has become irrelevant and is quickly fading into obscurity. It served a useful purpose at the time and it has certainly influenced the development of ES6 but other than allowing Ruby programmers to avoid writing JavaScript it's just no longer worth bothering with.
Also note that at the time everybody was trying to replace JavaScript with new languages (which were either supersets of JavaScript (like TypeScript), shared a common subset with JavaScript (like CoffeeScript) or did something else entirely (like ClojureScript)).
Babel is part of a general movement towards unification. Babel out of the box has support for JSX and type annotations (which are already just defined in terms of extensions to JS). Google's AtScript has been redefined as an extension to TypeScript (which in turn seems to be moving towards redefining itself as an extension to JS). I think this is a far more productive development than everybody trying to create their own compiled-to-JS language from scratch.
In a nutshell: I don't hate CoffeeScript, but I consider it a major smell when evaluating libraries and projects. If it's written in CoffeeScript it might as well not be written in JavaScript at all.
Yeah CoffeeScript is pretty easy to learn and doing things like configuring snippets seems like a good use for it.
In general tho, I am pretty hesitant to go all in with CoffeeScript, mainly because you still have to watch and massage the javascript output, negating any time saved for me at least.
The UI library is in coffee script; if you want use a UI for your plugin, youre pretty much stuck using it.
(..and yes, its technically possible to do with plain js, but I challenge any of the 'but just use js' folk to link to a popular plugin, with a UI, that does)
You can call CoffeeScript functions from JavaScript and vice versa. There's no reason that you can't use the UI library from code written in JS. The fact that its written in CoffeeScript is an implementation detail
