(Not that that is the only requirement you might have.)
All my scripts are in `package.json`. I don't use Grunt or Gulp. If I want to re-bundle my client, I invoke a script that essentially does `browserify -g uglifyify lib/browser.js > dist/main.min.js`. My JSX build script and the bundler script are automatically invoked by a watcher.
This[0] is my entire build script and the only reason it's verbose is because I like to be able to execute each task separately if I want to.
The only problem with React is that it is only a view library. It only does components. The blessed solution is a Flux-like architecture as implemented by Fluxxor or Reflux, but you can integrate React into nearly anything you already have. I like the immutable/unidirectional approach React and Flux share and ended up writing my own library[1] because there were things I didn't like about the existing Flux implementations, but you don't have to do that.
I have to admit that Flux has a steep learning curve. And if you've never dealt with immutability before it can really melt your brain. But I don't see how Meteor is any easier to pick up, especially considering that it comes with its own entirely separate ecosystem (the only non-node library I use in my React app is an XHR-wrapper that replaces `request` on the client).
1. "I have to admit that Flux has a steep learning curve." & "But I don't see how Meteor is any easier to pick up..." are mutually-exclusive.
2. Most everything else you wrote does a pretty good job of representing why Meteor is so attractive to some of us.
With Meteor, you're developing Meteor apps. Sure, you can put a different front-end in it or replace its server-side with an API compatible equivalent, but that's like saying you can use Django without its template system or ORM (if you don't know anything about Django: you can, but Django's built-ins provide a lot of synergy that you can only get from tight coupling).
