RFBYTE/WORD/LONG work in hub exec mode
I have tested RFBYTE/WORD/LONG in hub exec mode and they work, contrary to what the documentation says. They remove the byte/word/long after the next instruction from the FIFO. Possible uses for this are (a) to read data embedded within hub exec code, maybe put there by another cog and (b) to skip an instruction without any time penalty.
An example of (a):
rflong x <instr2> long $x_data rflong y <instr4> long $y_data
The main advantage of using RFxxxx is that takes only two cycles, much faster than the 9...26 cycles (+1 if long crossing) for RDxxxx in hub exec mode. Note that if you wait sufficient time after a hub exec branch for FIFO filling to finish, RDxxxx can take the same as in cog exec, 9...16 cycles (+1 if long crossing).
An example of (b):
if_nz rflong temp
<instr1>
_ret_ <instr2>
'return if z, continue if nz
Using RFLONG to skip instructions is equivalent to SKIPF with fixed skip pattern of %10. Hub exec doesn't support SKIPF itself. RFLONG removes the skipped instruction from the FIFO before it enters the instruction pipeline so it wastes no cycles, unlike SKIP.
RFVAR{S} did not work in hub exec mode in my tests. Consecutive RFBYTE/WORD/LONG also did not work. However, all RFxxxx can be used in cog exec after a routine in hub RAM returns. The data that RFxxxx reads start four bytes after the routine because the long directly after it has been read already as part of instruction pipelining. Note that a RDFAST is not needed before RFxxxx in this case because the former was done during the branch from cog to hub exec.
EDIT:
Added RFxxxx vs. RDxxxx time comparison.

Comments
Thieving data makes sense. And I'd come to the conclusion the FIFO doesn't terminate. It just stops being used.
Yes and the good thing is that RFxxxx doesn't interfere with an instruction fetch in hub exec. I might test RFVAR{S} again as the other RFxxxx work.
It's perfectly possible to do the following:
From cog/LUT exec, call a routine in hub RAM then after it returns do RFxxxx's to read data starting four bytes after the end of the routine, without ever needing a RDFAST.
Hmm... I was also under the impression that one can't touch the fifo in hubexec mode...
It will crash your program if not carefully crafted.