Definitely have a glance at the “Comparison to existing tools” section of that pull request, since much of that reasoning still applies.
The short answer is that the Meteor platform team has a commitment to backwards compatibility that projects like https://github.com/thereactivestack/meteor-webpack simply do not have. For example, it’s acceptable for such a project to say you can’t use Webpack-powered modules to implement Meteor packages, or that Webpack won’t run any existing compiler plugins for you, or that meteor shell won’t be able to import modules from your app (because Webpack knows nothing about meteor shell). These compromises are reasonable because using a Webpack integration plugin is totally optional. You don’t have to use it if you can’t get it to work with your existing apps and/or packages. If it works for you, and you’re excited to learn about Webpack, that’s great. If those requirements were barriers to using Meteor at all, or prevented Meteor developers from easily upgrading to version 1.3, it wouldn’t matter how awesome Webpack is (and it is awesome)—responding to bug reports about the Webpack integration would consume all of our time as core developers.
Even if we didn’t care about backwards compatibility, Webpack is a sophisticated tool that rewards thoughtful setup, and derives much of its value from being highly configurable. Introducing Webpack into a Meteor project (or any Node project, for that matter) means you have to start thinking about Webpack regularly: how to configure it, when to invoke it, which loader(s) to use when importing special file types, how exactly to respond when modules get hot-reloaded, etc. As with any sophisticated tool, the benefits of deeply understanding Webpack eventually outweigh the time spent learning how to use it, but it never fully fades from view.
Though this comparison may not be totally fair, we were able to use Babel as the implementation of the ecmascript package without asking Meteor developers to learn anything new besides ES2015 syntax, and they could even adopt the new syntax at their own pace. From the bottom of my heart, I wish the prospect of supporting Webpack felt more like that, but I just don’t see any way to reap the benefits of Webpack without burdening Meteor developers with its complexity. We care deeply about the slope of the Meteor learning curve, and Webpack presents a big initial hurdle, especially for developers who are not already sold on its benefits.
With all of that said, we very much appreciate input from developers who have chosen to use https://github.com/thereactivestack/meteor-webpack (or any other module system, e.g. https://atmospherejs.com/rocket/module or https://atmospherejs.com/universe/modules) with Meteor. The work you do to implement and validate your proofs of concept helps our planning and prioritization immensely, even if pesky considerations like backwards compatibility require a different implementation of those concepts.
We would love to support the most useful features of Webpack, such as code splitting and hot module reloading, though we may have to think carefully about the precise APIs, since require.ensure and module.hot both assume a CommonJS module system. (What does code splitting or hot module reloading look like in terms of ES2015 import and export? That’s a really interesting question, and unfortunately Webpack doesn’t have a long-term answer.)
To answer the original question, the API formerly known as Meteor.install (now just meteorInstall) is much worse than Webpack in terms of the features it provides. The initial goals of the Meteor module system are more modest: to allow Meteor developers to control file load order using ES2015 import and export syntax and/or CommonJS require and exports, to support a more modular application structure, to make it possible to load packages from node_modules directories on both the client and the server, and to work seamlessly with the existing Meteor build system. Supporting the features we know every Meteor developer needs right now, without claiming to support all that Webpack has to offer, should drastically improve the Meteor developer experience in the short term (~1.3) while leaving us the freedom to pull the best parts of any module system (Browserify, SystemJS, jspm, et al.) incrementally, as those features achieve consensus.
We’re going to be putting out an early beta version of Meteor 1.3 this week, and I encourage anyone who has read this far to give it a try!