My impression: it does more than vanilla browserify.
It also has the ability to specify async loading, and can pretty easily chunk up shared js files (such as vendor libs) into one file, while generating another specific js file for each entry-page/page.
Sometimes not doing things is a better approach. In browserify these kinds of features are implemented as third-party plugins (https://github.com/substack/browserify-handbook#partitioning), because that leaves far more room to capture the diversity of approaches. You could use factor-bundle to build the split bundles and place <script> tags or use xhr to load the bundles dynamically or you could use partition-bundle which handles more of that automatically but is harder to customize.
The abstractions are easy to swap out as your requirements change, but you've got to spend more time figuring out which plugin is more fitting.
Yeah - it does feel like browserify follows the unix approach (do one thing, but do it well) and leaves the rest to plugins.
But that's not always a good thing - you now have to find plugins for all your more 'advanced' use-cases. And anyone picking up your work might have to grog your chosen plugins as well. But it is simple.
Personally I still haven't fully decided which to use yet - still in the testing phase.