I'm not sure how "others" measure "easier", or "more robust", but as far as "faster" goes:
http://yuilibrary.com/~msweeney/yui-tests/taskspeed/
http://yuilibrary.com/~msweeney/yui-tests/slickspeed/

Yeah~ thanks. I saw this from the YUICONF2009, and thought "VERY COOL~" I'll just stick with YUI 3.

Hmm, I'm a bit late to this discussion

But yeah, awesome job Matt, seeing those were a nice surprise for the GA, and I'm sure it just keeps improving

Young, as far as your question about which is better, better is a moving target of what you're using it for.

Having used jQuery for 3 years, and YUI for only about 4 months, I'm probably slightly biased in that my mind tends to see code from a jQuery-ish view point.

For what jQuery is designed for, it's quite good, and the API is incredibly easy to use.
YUI3 has gotten a LOT closer to a lot of the good points of jQuery, though for pure ease of use, I would probably still give the nod to jQuery.

If you're looking to sprinkle ajax, animation, dom traversal and manipulation into a page, jQuery is great for that.

But where I found jQuery falls about really quickly and handles really poorly is if you intend to expand beyond dom manipulation.

The root concept of jQuery is "grab something, do something with it". It's very simple and flexible for, say, grabbing an element on the page, adding some styles and events to it.
It's even useful if you want to do some customized work via it's plugins.
And people have been able to stretch the concept to do some crazy and original stuff with the plugins architecture.

But what happens when you need components that include multiple elements in a dom structure? In jQuery, you would organize based on some root element, but the entire concept falls apart really quickly. Even though YUI3 widgets are somewhat similar (in that most widgets share a root element in the boundingBox), the fact that it's a planned architecture in YUI makes it MUCH easier to develop against.

Here's a good example. Let's say you want to have an overlay displays when a user clicks on a link, and is aligned to it.
In jQuery, most people would write a plugin that would do one of two things:
$('a.link').alignedOverlay({..options..})
That would attach the click handlers and create the overlay and wire up the logic.
But then what if you need to work with the actual overlay? You need to do another query against the DOM, or you need to read the "data" object from the element you originally ran the plugin on (and hopefully the plugin stored a reference to the overlay element for you to access).
But then what about using custom methods on that overlay? For instance, let's say that you've created your aligned overlay, but you want to realign it if the window resizes, here's a best case scenario of how you would do that:
var link = $('a.link').alignedOverlay(); // btw, what does link point to, the anchor or the overlay?
$(window).bind('resize', function(){
var overlay = link.data('alignedOverlay');
if(overlay){
overlay.align();
}
})

That's assuming that the data points to the JS instance of the overlay, and NOT the jQuery object that wraps the DOM element.

Long story short, jQuery focuses on the DOM, and this is it's strength, because for many people that's all they happen to care about to get something up and running.

But if you're building apps, it's not wise to think in terms of the DOM, but to think in terms of widgets that happens to contain dom objects in them, but also .

Plus, the other benefit is that you can still do the plugin method in YUI if that makes more sense.

The other benefit I see is that YUI also has the DOM-centric view of things, but it's relegated to the node package, which is just a tiny piece of the whole pie. Because that's the other aspect to YUI that is great is that it addresses a ton of needs and use cases.

I think there are definite pluses to both sides and definite downsides, so what makes sense is to go with what works for your needs.

I personally think that YUI3 has the best of both worlds

Yes, please, do.