After some digging, the only differences I've been able to find between the
re-plug behavior under X (where the encoder sends no signal although the driver
thinks DPMS is ON), and the re-plug behavior under an fbdev (where the signal
returns after re-plug, as expected) are the following:

  1. When the monitor is re-plugged and radeon_connector_hotplug is called,
connector->dpms is OFF in the fbdev case, but it's ON in the X case.  This
means that radeon_connector_hotplug returns immediately when the monitor is
re-plugged under fbdev, and that the code in radeon_connector_hotplug is not
what's turning the encoder back on.

  2. In the fbdev case, there are redundant calls to radeon_atom_encoder_dpms. 
When unplugging, it's called six times with on=false, and when re-plugging,
it's called thrice, with on=false, on=true, and on=true.  In the X case, it's
called only once per unplug/re-plug, with on=false and on=true, respectively.

  3. In the fbdev case, drm_crtc_helper_set_config is called on re-plug, and it
calls some other functions, including radeon_encoder_set_active_device and
drm_crtc_helper_set_mode.  (I realize that this may be a red herring, but
figure I should include it so that expert eyes may judge.) 
drm_crtc_helper_set_config isn't called at all in the X case.

  4. Forcing DPMS off with xset results in one call to
radeon_atom_encoder_dpms.  Forcing DPMS on with xset results in one call to
radeon_atom_encoder_dpms and one (I think?) call to drm_crtc_helper_set_config.

(I'm not counting calls to encoders and connectors not connected to my monitor,
even though fbdev likes to traverse them all anytime something changes.)

It seems that drm_crtc_helper_set_config is doing something with the encoder
that radeon_connector_hotplug is not doing.  This is my first time digging into
video code, so I have no idea what that might be.  I'm going to take a break
from working on this for now, but will come back to it if no one else beats me
to it.  :)