Some of the biggest arguments against using a framework like Bootstrap or Foundation, is that they are heavy, have inherited bad design choices, and overcomplicate things. Some people even go so far as to say to never use them. And these arguments are, at least semantically, right.
But the reality is this. You could have a totally lightweight, custom self-built car too.
You could forego the electronics you don't use, fix that annoying little lever that makes zero sense, and you could even throw out the automatic transmission and just drive stick. You could CNC every major part if you really really wanted to, especially if you have a team of friends at the ready to help you.
But what if it's just you and a buddy? How long would that take? How much expertise would you have to acquire just to get started? What is actually the goal? To get from A to B safely? To win awards? Where is the tipping point of value vs. time?
Balancing what is the right amount of learning vs. doing is a huge part of building web apps. Often what you build will be rebuilt in 2-3 years, or it could be up for ages. But what technologies you choose is always a bit of a gamble, you have to balance what is best for the client today with what will last through tomorrow. And the truth is there are no easy answers or guarantees.
That is not to say let's just start frameworking all the themes. You should take time to carefully consider whether or not a framework is for each project. I have a post on how to know. But here's what I've noticed.
People who hate framework's usually work on bigger teams, have more isolated tasks, and probably have been burned by poorly themed sites they've inherited. They also usually get at least a little play time with new technologies, built into their day/salary. Being skeptical works for them. Which is awesome! We need enterprise, mega development happening AND people that fight to make the web lighter and more semantic to keep things sane for the rest of us.
But the circumstances they have to work with is different from say a smaller team who has multiple clients to fit into a short span of billable time. This lack of extra hands makes the balance between time spent learning vs. doing so much more precarious.
I am a firm believer that you should care about what goes on behind the browser, especially if you are just a site builder and couldn't rewrite every bit of code. Reading code and knowing when it's bad is an essential skill, and something I'm going to write about in the future. But sometimes you need to ship quickly, and having a framework in your back pocket to fill in the gaps is a great way to start.
The other caveat is that, especially with smaller-ish Drupal projects, you are often handed incomplete designs. So when you ask for, say, the user login form's design, all you hear is "We don't have budget." or "I'll post that on 99 designs."
Which means you get a bullshit design that takes you longer in Drupal than it's worth, and just makes your client mad at you. To avoid all that a framework is a lovely way to show the client what they are going to get up front, while upselling them on other features you know you can tweak and implement off the bat.
There are also ways to mitigate some of the issues with frameworks by rolling your own Drupal theme, and for a lot of projects it can be a good middle of the road approach.
Work on my deep dive in a Bootstrap Sass version of the Quickstart your framework with D7 series is already under way. Interested? Join the list at the bottom of this page to get discounts and updates when the Bootstrap version launches!