The argument against was that we already have scripts (even though they need some updates), and that the compressed jQuery file is still over 20 kilobytes. Plus it’s an additional dependency that could introduce conflict with other choices we make later on.
In the end, we wound up choosing to include jQuery, for a couple of reasons. The first is that it makes the framework responsible for most of the code that’s likely to require more maintenance due to browser inconsistencies. When Internet Explorer 8 is released or Firefox 3.1 comes out, jQuery contributors are likely to find most of the bugs and inconsistencies and release an update that fixes them. Even if I have to fix some of those bugs, I’ve found that the frameworks still save time. I had to fix an Internet Explorer 5 bug in Prototype once, and I didn’t find it that difficult, even though most of Prototype’s source looks like magic to me.
The second is that incorporating the framework lowers the bar for adding new features to the Web site. If jQuery is already available, the barrier to writing new features is much lower than it is when writing those features from scratch, and I don’t have to revisit the decision whether or not to add a framework at that point. It becomes a tougher decision when you already have non-framework code in place.
There’s probably an economic argument to be made here about marginal costs. Adding a framework increases the fixed costs of an application in terms of time and complexity, although the simplest frameworks make these fixed costs almost negligible. There’s a cost involved with setting up the framework and learning enough about how it works to employ it effectively. However, the right framework will lower the marginal cost of new features.
My thought is that it’s almost always worth it to eat the fixed costs of using a well-chosen framework to gain the marginal cost benefits when writing new features.