For what's it's worth, I shot some 1080p and mixed in some SD for a video that ended up about 30 minutes long. Exported it from FCPX as a 62GB Prores file. Then, I ran it through HB, high profile, CQ=19, decomb=default to yield h.264 and h.265 versions of the same file:
-h.264 came out at 3.49GB vs
-h.265 version at 2.64GB,
...or about a 24.5% reduction in file size with all other settings identical.
What I couldn't do was get the h.265 version to play (got sound but no video: error message is: "VLC does not support the audio or video format "hev1"", even in the latest official version of VLC. This may be because both are 60fps.
File size savings is substantial though not quite the "about 50% savings" long touted for h.265 (though this is just one sample). Processing speed seemed to be about 1.3X slower than the h.264 render, but that's probably to be expected with what I presume to be a much more complex encoding algorithm. I'm guessing that will improve as the HB crew keep refining this new option and as those who develop the algorithm keep improving it as well.
Glad to see this show up in HB. Of course, I'm going to stand by until there's an

TV able to play back h.265 before starting to work on batch conversions of all my media, just to be sure that Apple doesn't throw some wrinkle into their implementation that would require re-rendering everything. I remember proactively encoding a bunch of video with 6 channel AAC assuming a next generation

TV would store surround that way and then convert it to AC-3 on the fly. Learned my lesson about assuming right there.