I think the word "target" in the question is unclear, or at least has been misinterpreted. Many of the answers here seem to be about why you would write your source code in ES6, but at least to me, the "target" code is the code that actually ends up executing (whether on the server or in the user's browser or whatever).
I think it all depends on your context and use case. If you're running code on the server, there's no reason to compile down to ES5 if you know that your node version can run your code without modification. At my company, we write browser-based tools for scientists, so we have a bit more flexibility in asking users to use modern browsers. We still use babel and target ES5, but we may move off of it before normal consumer websites do.
The runtime performance lost using ES6 features is minuscule compared to the runtime performance lost by using Node.js in the first place. If the difference in performance for the ES6 features actually matters then you have made a grave mistake using Node in the first place.
Are you comparing node to C or Go or something else?
It's funny, my big a-ha moment on performance happened when I was working at a bank and could only code in vba (i.e. excel). All of a sudden -- even on small data sets -- O(n^2) was unacceptable and I needed to think about algorithms to get to O(nlgn).
I think it all depends on your context and use case. If you're running code on the server, there's no reason to compile down to ES5 if you know that your node version can run your code without modification. At my company, we write browser-based tools for scientists, so we have a bit more flexibility in asking users to use modern browsers. We still use babel and target ES5, but we may move off of it before normal consumer websites do.