Please consider that:
1. Almost no one in the world has heard of Bootstrap. Though it's captured our mindshare as developers, most of our users will not know nor care if the app is Bootstrap or not.
2. The vast majority of web apps still will not be Bootstrap apps.
Basically none of the general public will say "Hey, this is a Bootstrap'ed application, I'm not using it." They just do not know nor care what Bootstrap is. If it looks professional and works as they expect, they will be happy. If they're happy, I'm happy.
If I haven't heard of it, none of my friends have. Out of the hundreds of people I know, I'd imagine possibly one of them has heard of Bootstrap.
Unless your startup target is web developers, nobody will have any clue what you're using as your UI kit, but they'll be pleased when things are where they normally are.
Last year I set out to create a set of example apps to bridge the gap between Michael Hartl's excellent tutorial and the piecemeal advice found on experts' blogs and Stack Overflow. The example apps are accompanied by tutorials (walkthroughs, really, not as thorough or informative as Hartl's book) and show how to set up a Rails app with authentication libraries (either Devise or OmniAuth), RSpec, Cucumber, and popular options such as MongoDB or Haml. Each has a companion application template that serves to generate a starter app. Like Michael Hartl, my contributors and I have seen increasing interest in Twitter Bootstrap and recently updated the app templates to offer a choice of front-end frameworks, including Zurb Foundation and Twitter Bootstrap (either Less or Sass versions). It seems Twitter Bootstrap for the front end is catching on -- fast -- for the same reasons Rails has succeeded on the back end: convention over configuration and a well-crafted implementation of commonly-used functionality.
Here are the RailsApps example apps, now with Twitter Bootstrap: http://railsapps.github.com/
A lot of the stuff people moan about (e.g. lack of backwards compatibility and constant breaking changes) is also what keeps it fresh. It's not hard to introduce new best practices because the old ones are continually tossed out. This can't be said for a lot of open source projects that value stability over change. (For some projects, stability is rightfully more important).
I really like tutoring and I am more than happy to help folks who want to build the next big thing.
However, first I make people write down their idea, set it aside, and forget about it. I tell them not to try to adapt this tutorial to their own idea, but just follow it to the letter and build the example application. It doesn't take that long.
Before anything, you need to know what you need to know. This tutorial has been and continues to be a great way to learn much of what you need to know... then you can go build the next big thing.
The main exception to this was for 2.0, which had a separate branch for a while so that people could still use bootstrap-sass while updating their application to the new syntax. When 2.0 was merged into master, since it had been under such heavy development I reconverted the entire codebase.
There are a few quirks with the conversion from Less to SCSS, but these tend to be few and far between, and are usually down to me missing a variable somewhere. The main one is the use of namespaced mixins. SCSS doesn't support this, so I have to prefix/suffix the namespace to each mixin within the namespace. Aside from that, and method names/variable notation, there (appears to be, can't speak authoritatively since I haven't really used Less) little difference between the two.
I'm not saying that's good or bad, but it's probably "why".
Don't misunderstand - It's not impossible to use less with other non-node.js based systems, but it is a massive PITA. There's a handy gem "less-rails-bootstrap" which wraps twitters bootstrap files and integrates with the Rails asset pipeline, but again, you should avoid this if you're not running on an up-to-date Intel system, since it has a dependency on "therubyracer" gem (which is V8 for ruby).
I have been using SimpLESS a little bit in the recent past, but it does choke on some of the bootstrap less files, and I haven't had the time to fork and rebuild it with a more up to date less library.
I think if I was coming to bootstrap now rather than a few weeks ago, I'd have chosen the sassified version rather than less, but fortunately I have an intel system to abuse, so all is not completely lost.
The motivation for the change was to please readers. Happy readers make for a happy author. Among other things, happy readers buy ebooks and screencasts. For a free online book, the Rails Tutorial makes a surprising amount of money. I'd like to keep that record going with the 2nd edition.
Blueprint did not factor a great deal in the original version and, honestly, Bootstrap is probably more relevant at this point.