That being said, setting up sourcemaps correctly can be a bear... But it's taken most of the pain away from our debugging issues.
And if that's not possible, as long as you aren't using some of the "heavy to transpile" features like async/await, looking at the translated code directly (and stepping through it) is generally close enough to get the gist of what's going on.
Edit: the bigger headache for me is code which loses it's full stack-trace, which is becoming more and more common when transpiling async/await for reasons I haven't had time to look into.
You'd still need to do some transpiling for imports/exports and JSX, though, depending on what you use. And running different code in development and production has its risks.
I actually tried this for a bit. I found that it really increased the complexity of the build system for not that much of a gain.
Instead of having a "dev" build and a "prod" build, we needed a "chromeDev", a "otherBrowsersDev", and a "prod" build.
So now you have 3 separate environments for your babel configs which you need to keep in-sync, and you run the risk of the semantics being slightly different natively vs the transpiled version (Which IMO isn't that bad when you go from transpiled->native as the transpiled is normally a subset of the "native" functionality, so you are less likely to hit issues)
What I've been doing is just writing in ES6 and testing on Chrome, then after its towards V 1.0 I'll add webpack to the staging branch.
Very little work to switch from a bunch of script tags to a bundle towards the end of active development, much faster than bundling every single time I change the code a little bit.
That is, of course, unless I have to compile typescript, then I'll just target ES5 anyways.
Edit: What he said /\