This is just my $0.02, but I'd argue that the problem isn't with NCM, but with a NAC solution that's allowed to make changes to device configs on its own. There's so much room for mistakes in that kind of setup, it gives me the willies just thinking about it.
Although in concept I tend to agree with you (I have found, for example, that automated IPS is problematic,) the nature of how NAC solutions do what they do requires automated command execution. A device connects to a switch port, and before the device is given some higher level of access, it is checked in various ways before being given more access (they use the term "posturing" for this.) This sort of thing is done with many solutions, Cisco CleanAccess, PacketFence, to name a few. We are comparing only MAC addresses, but the use of NAC requires that the NAC software talks to the switch. I have seen many other environments where the device is checked for antivirus, or watched/scanned for malware.
There are other scenarios that are similar but less chatty. Take AirDefense or other wireless IDS products for example. AirDefense detects a wireless access point as a "wired rogue" by first polling the switches looking for specific MAC information, than via a policy set forth by the AirDefense Admin, the AirDefense unit shuts the switch port down to prevent the security threats a wired rogue introduces. In this case, the automated interaction with the switch is less frequent, but still present.
Through the use of TACACS+ and AAA command sets, we can restrict what commands the NAC solution can execute on the devices/switches. This limits some of the risks.
