There is a third option: the Babel CLI lets you transpile the files one-by-one using babel -d outdir indir (where indir is your ES6+ source directory and outdir is where your ES5/ES3 code will live). This can help with debuggability if you don't want to or can't use source maps and is the approach we took with the arangojs module.
For your own applications you can instead use a single bundle but you will likely want to use source-map-support (via require('source-map-support').install(); in your entry file) to get more readable stacktraces.
The require hook can be useful in development but it means every file will be transpiled at run time. The performance implications aren't terrible if you don't have to load new modules all the time (most apps will just see an initial overhead on startup) but it also means a lot of tooling (i.e. all your babel related modules) are no longer devDependencies but regular dependencies -- your app needs them in order to work at runtime, meaning bigger deployment bundles and more moving parts in production.
Personally I only use the require hook for tests, because I want to be able to run the test cases without having to transpile the test files on the disk (they will of course still be transpiled when executed but only in-memory) during development. Ideally your tests should be executed against the exact same code you run in production but I'm willing to accept the trade-off for having tests run more quickly during development.
PS: as you mention using webpack for css-modules in another comment: if you want the magic of the webpack loaders, there's no way to do that with the multiple files approach. However if you only need that in your client, you can find a compromise by creating a client bundle only and loading that (webpack makes it easy to generate a server-side client bundle from a different entry point). Or, just use a server bundle (but make sure to exclude the node_modules folder from it to avoid problems with native modules).