Bandwidth and related performance issues aren't usually the big issue at shops that use jQuery or any of the other JS frameworks. More often, it's a matter of minimizing developer time and the related costs. The majority of developers who are fulfilling the UIE role are PHP, Java, ASP, etc. developers. They are not JS experts. In other cases, where the guy in the UIE hat isn't a developer in a server-side language, he's often not really a programmer at all; that is, many UIEs know lots about HTML and CSS and little of JS, except in the script-kiddie sense (they can Google up a script and barely tweak it to suit their own needs).
When it comes to performance-tuning and bandwidth reductions, there's a lot of lower hanging fruit than JS frameworks. You can optimize images, reduce the number of images, employ sprites to cut the number of GET requests, defer loading content into background and Ajax processes, etc.
My shop uses jQuery for CMS sites, since the open source CMS we employ for that purpose requires it on the client side. I do not ever use jQuery otherwise.
My major objection to the big frameworks is that they are most frequently used by people who don't understand what's going on under the hood. This may save time in the short run but leaves projects at great risk, if anything goes wrong; that is, you've got a very complex app in the hands of people who don't have the expertise to support it. I am ever (evilly) amused by requests for help that being like, "my app was working perfectly with {some JS library} until I added {some other JS library}, but now it's broken." These guys will not be fixing their own problems.
Bottom line is that's it's a spectrum. At one end, if you're using significant portions of jQuery and have a fair grasp of JS, it's probably not a waste of bandwidth (tho' other risks obtain). If you need only a little JS functionality or are a JS guru (I am), it's probably a waste.