From the post you brought up, http://spion.github.io/posts/analysis-generators-and-other-a... -- by the author of Genny. As I said, that's at least qualitatively the same as Q; quantitatively I haven't looked. At https://github.com/spion/genny there's the example line
require('genny').longStackSupport = true
and "This results with CPU overhead of approximately 500% and memory overhead of approximately 40%. In the future, the overhead will probably be eliminated in node but not in browsers." The benchmark post says Catcher is worse.The README for Q shows the same switch and says "This feature does come with somewhat-serious performance and memory overhead, however. If you're working with lots of promises, or trying to scale a server to many users, you should probably keep it off. But in development, go for it!"
I'm not a current user of any of these systems, but this is why I said the first-order cause of any performance difference appears to be that ClojureScript is not a library.
If you think those two libraries are just bad, I'll update somewhat in that direction.
Q explicitly says that you don't want to enable stack traces for production, which seems like a fairly high cost to pay. Neither core.async nor ES6 generators need to do anything special to have clean traces - it's fundamental to how the system works.
I'm not sure what you mean about async streams, but I wasn't seriously after more changes to JS syntax, just wishing (1) E had taken off and (2) new languages learn from it.
Sorry for not being clear, my posts are all part of continuum. My point is hardly anyone uses promises for fine grained asynchrony because of the costs and debugging indirection. My point is that you can do both coarse/fine grained asynchrony at little cost and without obfuscating your errors during development or in production if you move beyond promises.