React has a much richer notion of what a 'component' is. To date, most JavaScript libraries lack shared assumptions about how you will build your UI. jQuery plugins make only the extremely minimal assumption that you will apply the plugin to some DOM element - beyond that, how the plugins behave, how they manage their state, properties etc. is not defined by any standards or even assumptions.
The confirmation popover you link to is a good example. It's a black-box component which exposes a fairly minimal interface. The constructor for this component works like this:
new ConfirmationPopover(msg, [title])
To attach the popover to an element you need to do:
popover.show(el, [fn])
However, if we take another component from the same library, the swipe component[1], we see different conventions. Its constructor:
Swipe(el)
It also has a show method which takes totally different parameters:
.show(i, [ms], [options])
This is why I describe such systems as package managers or library managers - they're just a way of importing and exporting code and don't do anything to aid reuse. They're not particularly likely to play well together, lack standard interfaces and are almost certainly not composable in any meaningful way.
React components are different because React defines some standard details of how components behave, how to extend them, how to inspect them and pass data back and forth. Components can contain other components, and all components have a relative place in the render tree. This makes possible standard developer tools that can be used to observe and inspect components in a DOM-like tree structure[2].
So, you could certainly use bower to distribute React components. What's different about React isn't how the code is distributed but the fact that you can have expectations about how, say, a React photo gallery component would behave that you would not get from some other JS library.
[1] https://github.com/component/swipe
[2] http://facebook.github.io/react/blog/2014/01/02/react-chrome...