From a high level, I agree with the overall premise of the article - if you would only be using a miniscule fraction of the framework, then don't use it if you can get the same performance with a smaller footprint. It's better for your customer and better for their clients with better performance.
The problem with catch-all frameworks is their complexity, and often people can't find all the pieces without a ton of digging, which means they end up looking elsewhere and using ANOTHER framework (say jQuery + mooTools + the flavor of the month), or a plugin which has actually been replaced in the baseline code, but the documentation doesn't lend itself to knowing it's been replaced.
The other problem is layering - people put code on top of code on top of other code instead of refactoring constantly like they should always be doing. So you end up with 10 different ways to reach the same solution, then people add onto those 10 different ways, which adds a magnification problem on top of a simple solution...
I still have my old college professors mentality - keep it light and tight - when I approach ANY technology problem. The fewer layers I have to deal with, the easier it is to fix a problem when I go back to deal with it later. I've got a problem right now which is a pain in the maximus simply because there are too many files (at least 10) required to accomplish the same goal, and one of the biggest hurdles is the framework that was chosen wasn't flexible enough to handle anything other than straight table/database interaction.
Frameworks are great for what they're intended for, but they shouldn't be the be all and end all. They are tools to help you do the best job possible with the least amount of effort. HOWEVER - if you become solely dependent on them and can't do the simplest tasks without using them, then YOU'RE not a developer.