Not exactly sure what you're saying here.
I'm saying that languages like these (if I understand correctly), when compiled, result in a program generated by said language, "written" in another language, like Javascript, Java, Python or something.
Personally, I see no value in doing so. It creates a bit of an "overhead" (you compile it twice), and you actually don't really see what happens in the layer below the layer you're working in: the JS/Java/Python layer.
Say you've been working in the language FooBar, which creates, say, Javascript. Now most examples of code generators I've seen don't really care about the readability of the code they output. They have a readable, human-created bootstrap.js loading the default handler, and a bunch of semi-obfuscated .js floating around.
Usually, this doesn't matter. However, I see a lot of these languages appear on HN lately. The problem I'm starting to see is that, when we've got 10,000 alternatives to FooBar, people all start using different FooBar-like languages, and it becomes a mess. If you, for example, like to write in BarFoo, then we have a problem. We both understand JS, but the generated code is a mess. What do?
Then again I could be wrong. :P
Now, from the JavaScript target, yes, it compiles down to JavaScript, but it does so in a way that it not only provides sourcemaps to be able to debug, but also be consumed from JavaScript via Common JS modules for instance, thus allowing you to interact from JavaScript with the code you've written in Kotlin. Think for instance replication of some business logic on both client and server which is quite common.
Finally, in regard to writing Kotlin versus JavaScript, well Kotlin has it's advantages if you prefer static typing and want some of the benefits that language provides. If you're comfortable with JavaScript, if you prefer dynamic languages, then there's little reason to use Kotlin to compile to JavaScript (except the previous scenario of sharing code).