Downside: unusual behaviour. Users fully understand how to scroll to the top of a page to find the header. This hack already requires them to scroll up to get to the header. Also, there's a decent chance that if you're trying to find the header that you're going to leave the page, so it doesn't matter if you lose your spot.
It's a cutesy feature, but it's cumbersome and pointless, and doesn't add any real usability (unless you count getting rid of fixed headers, which also don't add any real usability).
In short, this element feels always somewhat out of user's control.
Much more usable on mobile would be putting such navigation in a kind of sidebar that many apps already employ (often accessible by swiping from the left edge of the screen), while on desktop a great solution is simple “top” links, strategically placed.
Plain fixed headers, possibly somewhat collapsing in height as you scroll, also seem better than vanishing headers from the point of control.
Unless there comes out some positive research on usability of this particular UI element, I personally am not convinced.
> Plain fixed headers, possibly somewhat collapsing in height as you scroll, also seem better than vanishing headers from the point of control.
Also, it's worth noting, that whilst the obvious use-case for the lib is headers; it can be used on any element, to have it react to scroll direction and distance. For instance, I've used it to make a sidebar fixed after scrolling past a certain point on the page (classic sticky sidebar pattern). Also, I've used it to only show a "back to top" link when a user is > 50% down the page and scrolling up quickly - so unless you're deep in a page and scrolling towards the top, the link will never be visible/distracting.
It works well for these scenarios too!