Yesterday I spent some time profiling the effect shown in this article:
http://engineeringblog.yelp.com/2015/01/animating-the-mobile-web.html (and here's the live m.yelp page)

During profiling I some interesting things, but two of which are specific to jQuery.

1. webKitMatchesSelector is being called during elem.is(':visible')
   2 ) jQuery handler for touchmove seems very slow. (This one we can punt to another ticket.)

A closer look at the is to matchesSelector stack:

Here's the a.rl method we're looking at:

a.rl = function(b) {
            return b.qu.is(":visible") || b.Ts.is(":visible")
        };

In total, this stack from a.rl through webKitMatchesSelector accounts for a full 15% of all time on CPU (including JS, recalc, paint, etc) during this effect, so certainly not trivial.

But this still strikes me as odd in the first place.

I don't think we would ever want a native qSA or matchesSelector to handle this sort of call, would we?