So I performance-checked all this. Here's what I found:

Accessing the native attributes are, of course, faster. Much, much faster. Noticeably... if you're testing thousands of these a second, which, fortunately, we're not.

I switched the code around to using some of the native accessors. I didn't perceive a difference, and even without switching, 97% of the time spent on the page was idle time, according to the profiler.

After a lot of back-and-forth, and reading through jQuery code, I decided not to change any of this. The reason is that, while it's technically faster, I'd have to duplicate a bunch of cross-browser code that jQuery already does, and then it just becomes closer to jQuery, with more of a maintenance burden.

Breaking this down:

1) For scrollTop, window.pageYOffset works most of the time, but not in IE in quirks mode, at which point we now have to go through a bunch of checks.
2) $(window).height() is a bit easier. It's just more wordy to get to the native value (document.documentElement.clientHeight). Easier to replace, certainly. Might as well do that in one of these cases. It's 8x faster than calling $window.height().
3) $(el).height() checks a bunch of things that we don't want to duplicate, so that's not worth it at all.
4) $(el).offset() also does some cross-browser compatibility checks that I don't want to duplicate.

Actually, the biggest speed improvement we can make is to cache $(window) whenever possible. That's crazy slow.

By the way, without changing anything else, caching $(window) on the view made the collapse button's position updating go from sorta choppy (it's clear we're updating it) to absolutely fixed in place, no stutter at all.

Also, sounds like $(window).height() may end up changing to be more accurate in some cases in the future, as they're trying to figure out issues surrounding some mobile browsers. So I'm choosing to go with that so we don't hit any future issues.

Huh. It's never defined in the old code either. Guess we don't need it!