It would be useful to have the loaders available to those using three via the npm package. Thus I am looking to add this later today.
I am unsure of the best way to provide multiple three package options to users. Of course I can keep including everything into the default package but then everyone gets everything whether or not they need it all. Another alternative is to create many different three packages, such as three-webgl, three-canvas, three-webgl-full, etc, but that seems like it could go on forever.
So right now I am defaulting to including more and more into the default three package unless someone has a better idea.
A library that polyfilled XHR for node (within reason) would be useful. You could check if you're in node and then require the XHR polyfill which would only be a one or two line addition to the existing three.js codebase. The way I do it is use an abstract library on both sides that shares the same API (namely https://npmjs.org/package/request and https://npmjs.org/package/browser-request) but this requires more of an embrace of node in terms of project organization.
I think keeping three as a single module that did some feature detection/polyfilling would be good for its simplicity. My only beef with it right now in node-land is how you can't load multiple copies of three at once (described here maxogden/voxel-mesh#5, sorry I haven't made a proper test case for this yet)
For examples/js I find separate modules to be a bit better:
var Controls = require('three-orbit-controls')(THREE)
This allows it to be useful outside of the scope of the three npm package (i.e. for those using <script> tag, browserify-shim, bower, etc) and lets things build on those modules (like three-orbit-viewer).