Interesting idea, I'd never thought about it, but it does make sense if you think about it.
Scenario, unsecured location and hacker gets into your wiring closet, uses password recovery methods to get in to your device and change the configuration so they can still get into it and compromise it once its back in the network and somehow leverages that to get further into your network, maybe doing things like configuring SPAN ports to monitor traffic, etc. etc...
The device is offline when the changes are made, so no trap or syslog make it out to your server to say that the config has changed. If the device simply comes back online without NCM checking its configuration to make sure it hasn't changed, you'd have no idea a change was made until your next scheduled download or someone logging into the device and making a change.
So, yes, this does make sense to me...
Have you tried delaying the config download action for maybe 60 seconds or something? It's possible that the device spews out the trap or syslog before its ready to be logged into?
Also wondering if it would be smart to try and monitor uptime and figure out a way where if the uptime is lower to do the same thing? That way if the device was reconfigured to NOT send syslogs or traps after rebooting, or was kept offline while these messages were sent, that it would still trigger a RTCD...
Got me thinking a bit...