Since I discovered it a few years ago, I've been a big Prototype fan. It's simple, and gets the job done with a minimum of fuss. It's not without warts, of course. I still occasionally forget to put 'new' in front of Ajax.Request, and some of the Ruby-like methods share their lineage's arcane naming. When it was new, it was the best thing around, and while it now has competitors, it's certainly not lagging behind.
At work, however, jQuery has been adopted as the standard (and I've no power to change it). The lack of the $() function is annoying; several times I've debated adding this function (or one of various similar ones) to our library:
function $(id) {
return jQuery("#" + id)[0];
}
I haven't, of course, as it's not the jQuery way. jQuery also lacks any sort of class assistance, so we still use the Prototype class framework for our class-based JS. That seems to work fairly well, except for the fact that we have to use two frameworks where one could suffice.
jQuery is not without it's benefits, of course. The plugin architecture is a nice aspect that Prototype didn't really offer an equivalent of. It means the core stays lighter (good), but if you want additional functionality you're stuck managing files from a bunch of different projects (annoying). Event handling is a bit more straightforward, in some ways. "Magically" acting on collections of elements with a single call (i.e. no .each(function(o){…}) garbage) definitely makes for more readable code as well.
Because of this shift at work, I've been porting some of my personal apps over to jQuery as well. I've actually been using a couple jQuery plugins (both self-written and external) for specific tasks for a while now, but not the core framework. What I've found, however, is that jQuery can be prone to slow code. To avoid a huge amount of extra work on the part of the JS interpreter, using temporary variables for jQuery objects is essential. If you do strictly id-based queries, the degradation isn't huge, but if you do CSS-based queries, it can be significant. With Prototype's focus on id-based queries (at least until $$() came about in 1.5), that was less of an issue.
This need to query a minimum number of times can provide a fair amount of complexity when you have more than a handful of closures hanging about and/or a dynamic DOM. You end up doing a lot of state management work because you're, in effect, caching DOM lookups and have to ensure you never have stale cache.
Other than that issue and the lack of an equivalent to document.viewport, porting has been relatively painless. Still very id heavy, so not leveraging jQuery as much as could be, but most of what I'm doing wouldn't benefit from other selectors.
Which one is better? Hard to say. jQuery seems to make you work harder to type less code, while Prototype seems to cost you a few more characters for a bit less density. With the exception of Prototype's class support, their feature sets are fairly equivalent, especially with jQuery UI now available to "compete" with Scriptaculous. For the moment, I'm choosing to use jQuery on new stuff, but wishing for Prototype every few minutes. Until I come up against some sort of significant wall, it'll probably stay that way, just to stick with the same tooling professionally and personally. And over time it'll probably get better as the Prototype-ness fades from apps.