Seems like the "reimplemented" portions are bits that need to interact directly with the script environment -- String is implemented in terms of V8's native strings, etc... That seems like a feature, not a bug -- you wouldn't want the interpreter needlessly doing bytewise diddling of an abstraction that is already very robust in the host environment.
In the Java Class Library, any function that needs to interact with the environment outside of the JVM itself (OS/file system/network/threading/etc.) is implemented in C and is marked as 'native'. Those are the functions that we explicitly implement for the JavaScript/browser environment.
You are right that we could extract more performance by mapping particular classes directly onto efficient browser functionality -- such as String. In the future, we could implement specific classes such as String directly in JavaScript for a performance boost. :)
As a side note, ASM.js itself does not have a String type, which leads me to believe that this particular optimization might not be beneficial if we switch to an efficient JIT strategy.
asm.js doesn't because C doesn't, fundamentally. Given both Java and JavaScript strings are immutable, you probably want to for the sake of having non-copying operations for substring and the like.
