Or they can also be used in place of asynchronous lists (like "object streams"). I find them handy for various tasks :)
Regarding es6-promise, its too minimal for my taste, and missing my favorite feature (provided by bluebird. when and p-promise): long stack traces on (possibly) unhandled errors, which are quite invaluable on the server side when debugging longer chains of events. p-promise has the additional advantage of being a relatively small library which is pretty awesome :)
[1]: example: flux implemented with rxjs: https://github.com/fdecampredon/react-rxjs-todomvc
I actually have this entire stack running without observables currently, and my goal is to build a variety of applications using it to really sort out the best techniques with it, and then open source it as a platform.
As for #7. I use webpack and love it. It does work wonderfully server side as well, you just have a build step with webpack that strips out anything you don't want for the server, and then have your server run that built file. Not perfect, but works well. It also avoids any need for gulp.
1. Not a problem, though I don't use either, I tend to use very small modules (not necessarily via npm, but require'd in my own project, or outside modules)
2. React, and even the Yahoo flux tools are pretty nice. React by itself is less useful.
3. I'd go with es6-promise here, which complies with the spec. I wrote i-promise as a module to give an ES6 compatible promise library, or native as available.
4. Observables are pretty evil... the whole flux architecture is to avoid direct observations in favor of a unidirectional data flow.. but that's more opinion.
5. completely agreed... immutable data flows work to prevent side effects. Even if you don't use these libraries, avoiding side effects is a big thing.
6. Also agreed, though you can usually get the parts you want without the weird deep dependency chains in lodash.
7. Agreed here, though webpack is interesting, imho it breaks too much with node's approach to includes, and doesn't work as well with reusing code on the server-side (imho).
Other things to look into include csp, streams, events and the gulp build tool.