I actually think this is a rather smart pattern.
Just to clarify on terminology (I'm using Twitter Bootstrap as a reference):
- Static Menu - a menu that scrolls away with the rest of the view (ie, will not be visible after scrolling).
- Fixed Menu - a menu that is constantly in the view, regardless of scroll.
- Autoshow Fixed Menu - a menu that hides itself on scroll down, and shows itself on scroll up.
Now consider the case of a static menu:
- As you scroll down it disappears.
- You need to scroll all the way up to show it again.
- Particularly annoying with mobile devices, where content is narrow and long.
In comparison, the Autoshow Fixed Menu saves the user the need to scroll all the way up (which could be quite a few hand gestures). The assumption is that the content is read top-to-bottom and menu interaction is needed after X amount of scrolls down.
As you mentioned, this allows more content to be seen on the screen, which is more important with mobile devices.
Now it's hard to find a serious flow in this behaviour, since users are accustomed to scrolling all the way up to see the menu. In addition, users should easily conclude that if the menu disappears on scroll down, it will show on scroll up (opposite action).
My point is that regardless of how you look at it, learning the behaviour of this pattern should be easy and instant.
This pattern is good when the template in question involves lengthy content, with scrolling being more frequent that menu interaction.
My assumption is that you are going to see more and more of this in content rich applications. One extreme example is Pinterest - as a content-centred application, many interaction controls are shown after an additional user action (click, for instance, will show various interaction options). Pinterest for mobile not only shows/hide the top menu, but also a bottom one.