Hey, it makes more sense now, sorry I couldn’t understand the first time around.
So, I’m not the most expert, so a maintainer of ClojureScript would know better. But this is my understanding.
You can see some of this in the source code: https://github.com/clojure/clojurescript/commit/b14eda36ca7249983f5c8f05b97e79bb45623a0e
As I understand it also, no new version of ECMA, have added any new primitives, or changed the memory model. So all the new features are higher level, either syntactic, or added higher constructs which might be more optimized, like its new data-structures. By higher level, I mean that no new VM level support was needed.
ClojureScript though, has always made use of highly optimized higher level constructs from the Google Closure library such as StringBuffers, Google Arrays, Google crypto, etc. When it make sense.
In this regard, I’m not sure it needs any of the ES6 ones. You might even wonder who’s are more optimized, the es-next standard ones, or the Google ones. Anyhow, they probably get close in performance.
You can geek out even more on this by exploring the source. This is the magic for the compiler in terms of what it emits: https://github.com/clojure/clojurescript/blob/3a6e71e4bb01f97c7a86f46bfed003a602ed5ad3/src/main/clojure/cljs/compiler.cljc#L176
This https://github.com/clojure/clojurescript/tree/3a6e71e4bb01f97c7a86f46bfed003a602ed5ad3/src/main/cljs is where the standard ClojureScript library is implemented. If you inspect it, and believe certain things would be faster if they used es6 constructs, like a WeakMap, or a Proxy, etc. I think you could make a patch to the JIRA, if its compatible with Google Closure compiler, I think it would get merged in.
That’s my 2 cents.
David Nolen would obviously know better then poor me