A lot of reasons actually.
* Webpack isn't religious and plays well with CommonJS, AMD, whatever. We almost didn't have to change the code when ported from RequireJS.
* Browserify's "all in one bundle" approach is precisely what we wanted to get away from, because our codebase grew like crazy. Webpack supports [code splitting][1] which allowed us to cut initial JS by half.
* As Pete Hunt said on some thread I can't find now, Browserify doesn't bring anything really new to the table. Webpack, on the other hand, brings "loaders" (first-class support for applying cacheable transformations as a build step for module). While they are not documented very well[2], they allow insane extensibility. They can be used for anything, from declarative code splitting with require() returning a promise[3], to compiling LESS[4], to bundling CSS as a JS dependency[5], to running JSHint[6].
* Hot Module Replacement gives each module an API to declare how it reacts to its dependencies being updated[7]. Loaders can use this API too, e.g. `style-loader` uses HMR to replace stylesheet without reloading the page[8], so you don't need to write extra code.
The biggest downside right now is the documentation being too technical. In the long run though, I believe Webpack will get more popular once its docs are improved, because it's just crazy powerful and extensible.
[1]: https://github.com/webpack/docs/wiki/code-splitting
[2]: https://github.com/webpack/webpack/issues/360
[3]: https://github.com/gaearon/promise-loader
[4]: https://github.com/webpack/less-loader
[5]: https://www.npmjs.org/package/style-loader
[6]: https://github.com/webpack/jshint-loader
[7]: http://webpack.github.io/docs/hot-module-replacement-with-we...
[8]: https://github.com/webpack/docs/wiki/hot-module-replacement