Jen Kramer, in an article on Smashing Magazine (emphasis mine):
A framework is intended to get a website running quickly, with minimum debugging. Customize the heck out of it to look completely different, or change just a few colors and be done. However you use it, you’ll have standardized, documented code that can be easily passed on to another developer for maintenance and tweaking and that looks reasonable and functions well. The code is not perfect of course, but it’s pretty good. It cuts down the time required to create a website, which will make the website cost a bit less, too.
You can replace “website” with “web UI” in that quote. If you are an avid reader of this blog, you know that we like open source and standardisation of building blocks. There are many technical reasons to do so, but there is also a very good business reason, which I find is often misunderstood.
Jen argues that using a framework cuts down build time and thus costs. I realise this was not the big point of her article, but I regularly hear the same argument in conversations with other designers, project managers or business owners. While cutting costs certainly can be a result, it is not the only possible outcome. Building faster can just as well mean iterating and testing more often. It can mean that you have time to focus on parts of the design that matter most. Building faster can mean designing a better product.
Using a framework frees up time. As a company, you can cash in on that time, or you can use it to make your product better. We use standard building blocks because we believe it benefits the product, not our wallets.