Module composition. With the most frequent styles being: CommonJS and AMD.
Because of m ybias towards CommonJS because of Node.js and the fact that I agree with TJ Holowaychuk that AMD is ugly, automatically rules out any solution that prefers AMD, namely: RequireJS, Volo, or Jam. Bower is intriguing because it does a great job of client-side dependency management and it was created by Twitter, so there is a big name backing it. However, Bower doesn't care if you use AMD or CommonJS. I cared more about using CommonJS in the browser than I did package management. So, it's preferable to find a solution that does dependency management and CommonJS.
Simple to use. If you're already using Node.js and NPM, there isn't much you need to do with Browserify, other than require your code client-side. There is no dependency listing or anything like that, Browserify will traverse your require() statements and include the necessary code.
There is no dependency management. This could be a pro as well if you're satisfied with NPM for dependency management.
It may feel a bit magical. You can use EventEmitter and other Node.js core modules on the client.
Build step. (A watcher can help this)
Client-side libraries in NPM feels weird and a bit wrong.
NPM dependency graph could get bloated if you include the wrong module client-side. i.e. The same module with different versions.
Documentation is really bad.
Node.js naming conflicts. Getting harder to come up with good names. Fortunately you can just append a .js to give yourself more choices but will probably introduce ambiguity.
Encouragement of simplicity. This could become a bit unwieldy because some Component modules are just a few lines. Your app might need 100's of components. But again, this could be a big plus.
Github is the de facto repository for storage and retrieval of your components. This makes publishing easy.
Github style naming. i.e. jprichardson/mymodule vs tjholowaychuk/mymodule.
Momentum seems to be increasing.
Feels like there is a bit too much ceremony to get up and going if you're already using NPM. This makes sense given that it supports dependency management though.
Component is hard to Google. Anytime you Google anything with the search term Component, a lot of unrelated articles come up. Picking such a generic name was a bad idea IMHO. Overtime, this may get better.
HTTP only remotes. You can have private Component repos, but it must support HTTP. I know that this https://github.com/godmodelabs/contre can help with that. I really bothers me. I'd like to component install email@example.com/var/lib/git/mymodule.git.
Extra component.json file. I'm being a bit nitpicky here, but managing the version number in two places (assuming you have a package.json) sucks. I understand TJ's reason for doing this though.