Rollup's gains come mainly from the way it combines modules into a single scope, rather than wrapping them in functions and shipping a module loader with the bundle. It's not uncommon to see parse/evaluate time plummet when switching to Rollup because of this, which is often more important than the number of bytes.

However Rollup currently lacks a lot of features that make Webpack a good choice for large and complex apps.

You can get a feel for the code Rollup generates at http://rollupjs.org.

FWIW, Rollup's tree shaking results in a little smaller bundle than Webpack 2's and faster execution speed of the optimized code from testing of using it with ng-bootstrap (an Angular 2 library on top of Bootstrap), but not significant enough for us to justify moving our demo to Rollup.

That is just one situation though.

Webpack still uses module wrappers, so tree shaking is mediocre in it (and I don't know if its still the case, but in some situations Webpack used to make the bundle LARGER when tree shaking was enabled).

The way we're looking at it, you use rollup to pre-bundle libraries where you want all of the dependencies inline and use tree shaking to make those as small as possible. You then consume rollup's output from Webpack, thus making dev time builds much, much faster and the resulting output super small.