It is an ambiguous thing because Bootstrap is not usually treated as a library, but rather as project scaffolding. That is, it's used to start a project, rather than enhance a currently built project. This is not necessary, of course, as Bootstrap is really a set of adjunct resources that can be pulled into your pages as necessary.
The major problem you see with this useage is that people start a project with Bootstrap 1.2, and 2.0 comes out, there's no chance in hell that they upgrade. Partly this is ignorance, partly this is because there is still no good package manager for the open web - and that's not for lack of coding chops, but because, IMHO, we're still not really sure what "package manager for the open web" should mean.
A page as an execution environment is both incredibly rich and incredibly risky. As much as the web itself is a wild-west of innovation, so is the page environment. We can pull scripts, images, css, data and even DOM from around the world. And for the most part we still do it by adding a line in the page and, if we want a local copy, a wget. The only reason resources don't step on each other is luck and convention - usually it's mostly luck (although the "single global object per library" convention for javascript seems to work really really well.)
It's time that coders and designers both start to think of CSS as reactive functions that map from DOM to pixels and are invoked with class names and ids (this is a lot different than their intended uses, but let's face it, semantic markup doesn't really meet any real human need). Perhaps, echoing the success of the javascript convention, we should adopt a convention that lets css libraries to exist within a single, top-level selector.
Projects like Meteor, Derby and AngularJS are a good push in the right direction, but there's still a long ways to go I think.
Just on the point about upgrading, I can remember between two versions of Bootstrap where markup changes were required in order for the site to function properly with the new release, and no backwards compatibility was provided. Unless somebody is waiting for new features in the latest release, I can see them not wanting to bother going through and updating all of their forms or views. However, if the new features are compelling, it will be worth the effort. Really this is the same decision process we go through when deciding whether or not to upgrade any underlying framework or supporting software.
The only bad thing I see about Twitter Bootstrap, due to it's success, is that seems to be used everywhere and so many startup projects all look the same.
Do they all look different to people who aren't designers/devs? I don't know, but as a developer, when I see a new project I have become oblivious to the design and find it challenging sometimes to see past the "just another app built with twitter bootstrap" to find the application's true value
in bootui we've tried to make some of the templates look totally non-bootstrapy. Of course custom bootstrap template requests are welcome! Do get in touch if you need something.
It was never mean to be modular; just to be extended and modified in a per-project basis, just an starting point for fast design development. You are suppose to be able to just use some part of bootstrap but many of this extensions assume that you are using it fully; and also there is no way of handling conflicts between extensions because this are just a bunch of files with no console or control panel to do a proper administration.
So far I'm pretty sure that's not a bad thing.