Some quick background, important for what follows.  Coco is a language that compiles to Javascript.  It has tons of fancy features inspired by Perl and Ruby and Python.  We don't use the vast majority of them in Limn.  We use Coco because it's more productive than Javascript once you get comfortable with it.  This took about two weeks for me and personally I think it was worth it.  I'm happy to address specific points that others like Terry and Ori raised about Coco.  Not all my answers will favor Coco but overall I like it.  The second important thing is that Coffeescript is strictly worse than Coco.  That's pretty easy to show and I point you to the satyr github page for examples.

Diederik, you estimate that the choice of language for Limn should be done before a new resource is hired to work on it and before we resume development of fixes/features.  I am not so sure this is true.  I think once we hire a talented Javascript developer and we decide as an organization what we want out of our visualization solution (read: not just Limn), we can make a much more informed decision.  And there are other things to consider.  For example Livescript is pretty popular.  WebStorm *could* make Javascript development much more productive than it has been historically.  Pure D3 might have become mature enough for us to rethink using it outright.  And so on.  I think at the moment we'd be giving an answer without a question.

Christian, as for historical reasons David used Coco.  It's honestly mostly because it's a better more productive language and partly because David is a hardcore aesthete who seriously dislikes meaningless characters like brackets, etc.

Ori, I think your point about Limn not being the answer forever is great.  We really do need to talk about what we want out of visualization and why we can't use the many, increasingly sophisticated frameworks being developed.  Like pure D3 with a few templates or plugins via Rickshaw, Vega, etc.  But, as to what's valuable in the non-library 250k or so of Limn code.  The purpose of Limn was to make it fun to play with data in real time.  We had to stop working on Limn before we could show progress towards that goal.  The one unique thing in that 250k is the marriage of D3 with Knockout.  This establishes a novel way of writing visualization components that are compatible with the end goal by design, out of the box.  In other words, we now have only to write the UI via which people would actually play with the data.  We know of no other work in this space and it's very exciting.  It's the kind of stuff that Brett Victor was playing with in Tangle JS, and we would really further that kind of deep, intuitive understanding of data if we went forward.

So my suggestion is to figure out what we want first, and who's going to work on it.  Then if we want pure Javascript, it would take a half hour to compile the Coco down and change some parts of the dev and build processes.