As an IDLE maintainer, I am a tkinter user also and that is my involvement in tkinter changes.  One of my projects for IDLE has been to switch to ttk widgets, including ttk.Frame, wherever possible, for the reasons you gave.

It is known the tkinter docs we control are quite inadequate, and dependent on outside docs that we do not control.  That is why the tkinter doc starts with 7 references for tkinter and 5 for tcl/tk.  I am sorry that you fell into one of the gaps.  But no one has yet volunteered to rewrite the tkinter/ttk docs to be complete, correct, and not dependent on outside resources.  Until then, I do not see a good place to put the note you request.  What would you say, and more important, where?

wm_manage is an anomaly for at least two reasons.  The tk docs define the wm call sequences as "'wm' <subcommand> atoplevel <maybe subcommand args>".  This translates to tkinters calls "atoplevel.wm_subcommand(subcommand_args)", where 'atoplevel' is the self arg for the call.  The tk doc contradicts itself by saying that for wm_manage, atoplevel can instead be a *frame* or *labelframe* (** indicates italics in the tk docs).  For tkinter, this translate to aframe.wm_manage(), but this is impossible since Frames do not subclass the Wm class, nor are they given this one method.  It also turns out that atoplevel.wm_manage() does not work either.

Instead, one must call atoplevel.wm_manage(toplevel_frame_or_labelframe).  This would roughly be equivalent, in tk, to "'wm' 'manage' atoplevel toplevel_frame_or_labelframe". 

Another anomaly is that wm_manage is not really needed, at least not for frames.  On can create a toplevel and pack a frame of any type that fills the toplevel.  (Yes, a bit more work.)