Section "Update Rescue Kernel" contains the following advice:

If the rescue kernel is out-of-date, then issue the following commands to regenerate it.
sudo rm /boot/rescue
sudo kernel-install add "$(uname -r)" "/lib/modules/$(uname -r)/vmlinuz"

This advice is pretty dangerous. If the rescue kernel has failed to be updated, the most likely reason is that an error is occurring in generating the updated kernel. In my case, the root cause (after a few levels of consequences) was a known problem with the boot install process in F39. Following the advice in the documentation left me with a system with no installed kernel (I actually hesitated before doing this, but laziness won out). Fortunately, documentation tracing appears to have found the appropriate fixes - not yet tested by reboot, though).

New users following this advice may well be left with no rescue kernel (and possibly no idea that that has happened), or at worst a bricked system (no kernel -- which may not be obvious until the next reboot), and no idea how to unbrick it. This needs to be fixed. The obvious fix is to put the new kernel install first. Then give the user some pointers on how to check whether the install succeeded, and where to look if it fails. Only after the install has succeeded should the old rescue kernels be removed. It makes the line to remove the old rescue kernels a bit more complex, but it's a helluva lot safer.

Note: there may be a temptation to treat this as just a consequence of the bug underlying the known problem with the boot install process in F39, and leave it to that process. However even if that problem gets fixed, the underlying problem remains: removing the old rescue kernels before making sure that the new rescue kernel can be generated is too dangerous.