jQuery minified is ~90K. Even if 2.0 weights half as much, 45K isn't that big a deal, even on mobile. Besides, it's so widely used that if you link to Google's CDN, it's probably cached already.
Second, just some hours ago, I read that the mere execution (not the download!) of jQuery takes about a second on an iPhone 3G. These devices and similarly weak ones are still out there, which is easy to forget if you test only on the latest hardware.
Lastly, keep in mind that bandwidth isn't always ideal. Consider mobile: In rural areas, 3G isn't always available. When I'm on the train, loading the slim HN itself often is not an issue, while many other pages simply time out. In developing countries, bandwidths are often very low, too. 56kbps still is a realistic bandwidth. And downloading 45K on a 56kbps connection takes almost 7s.
I'm all for efficiency, I'll use Zepto or a focused custom made solutions whenever I can, I'll squeeze every byte out of the images, serve resolution specific versions, gzip, etc.
But there are some compromises that I'm not willing to make. Take images for example. If I can see image quality degradation on something that I find important, I won't compress it further, even if it's huge. Add a few iPad retina display PNGs and suddenly 45KB seems like small change. Sometimes I'd rather have the user wait for a great result than deliver a poor one fast.
In the case of jQuery 2.0, dropping IE8 support seems a poor and premature kind of optimization. If your target is a memory starved 128MB iPhone 3G on Edge, than 45K for a single JS library is still way too much. Not only it would take forever to load and run, but unresponsiveness and eventual crashing would still be a problem.
I think the effort would be better spent on improving jQuery mobile. People on 56kbps connections could be running even older versions of IE.