I tried to help someone fix her CSS - for some reason her footer appeared before the containing the content. I used "Inspect Element" in Chrome Dev Tools and determined that the problem was due to the contents element having a float: left element. I let her know this, and she said: "I am using Bourbon, so I don't worry about floating, because bourbon takes care of that for me."
In another instance, she asked me whether she should learn Gulp. I asked, "Why do you want to learn Gulp?" She said, "Because it does auto-prefixing, and deployment, and lots more for me so I don't have to worry about it."
I heard a story where a software startup wrote their app in AngularJS, found significant performance problems, and upon being unable to solve them, rewrote the app using Backbone and Marionette. Actually, I've heard more than one story like this, you probably have too. Just substitute in different framework names and you have your standard: Why we ditched X and rewrote our app in Y story.
So what is the problem? Well, one problem is overhead. Rewriting an app is an enourmous undertaking. Joel Spolsky advices against it at all costs. I take a more nuanced view - that one should weigh the costs vs the benefits of a rewrite, and better to rewrite bit by bit as opposed to all at once. In any case, clearly, rewriting a app incurs a big cost to a business' bottom line. In fact, this is similarly the case with big upgrades. How many of you know someone who is still working on upgrading from Rails 3 to Rails 4? How about upgrading to the latest version of Ember? Furthermore, rewriting an app doesn't guarantee that you'll end up with a better app. You'll just get a different app with a different set of problems. I have personally used plenty of software in which I much prefer an older version then the newer version.
All of that being said, over-rewriting is but a symptom of a deeper problem: over-reliance. When you carry the expectation that the framework of your choice is going to solve all your problems, what you don't expect is to have to solve any problems yourself. "That's not my area". In effect what you've done is outsource your architecture decision making. But when you do this, you stop working out your problem solving muscles, and those muscles atrophy - or in some cases never even get a chance to develop. You will feel like if there's a problem, and your framework can't solve it, then it cannot be solved. You've learned to be helpless. Except, maybe... with an even better framework, one that will solve this problem and more! In other words, the grass is always greener on the other side.
But no framework will solve all the problems, no matter what framework or tool you decide to use, there will always be problems. Projects don't fail because the people chose the wrong framework. Projects fail because the people have the wrong mindset.