Currently it's still recommended to assume that
- new HTML5 elements' native roles are not mapped (and so when appropriate, use the aria landmark and other roles as a continued stopgap)
- the HTML5 outline is not seen (or not seen correctly) by the browsers (also, there is talk of maybe just scrapping outline altogether, but I dunno how serious that was)
- that headings still get manually-set levels
In other words, if you try to rely on the outline to translate <h1> everywhere to the appropriate levels, you should assume most users of AT will simply see nothing more than lots and lots of h1's, rather than the appropriate levels you intend.
Since navigation by headings (and heading levels) is an important type of navigation for users of AT, manually using the correct levels is still recommended. For now.
The real intended benefit of the HTML5 outline was, mostly, for syndication. Is your system going to be incorporating random chunks of user-created data which may have its own complete document-like structure? (For example, complete <articles> or <sections> complete with their own <headers> and <footers> and whatnot?)
Another thing to keep in mind is, while you can get data for "how does the latest JAWS/whomever deal with [some HTML5 thing]", keep in mind that the commercial AT software out there is expensive, and you can probably assume you'll have users with older versions.
Users of free/open source versions may be more up to date, of course. But there are more than screen readers: for speech-control programs I only really know of Dragon Naturally Speaking/Dictate/other products, and I don't know of any free version of those. There are also screen magnifiers which may or may not be used with a screen reader... and if used with a screen reader may affect what the screen reader reads out.