I have two cases where this would be helpful.
In the first case I'm trying to debug a driver which uses Telnet. The board which is the Telnet host can only receive one session. So I don't have an easy way to stop the driver and Telnet into the board to gather information. Changing the IP on the driver was not sufficient and required a reboot of the hub to take effect.
In the second case I'm also trying to debug a driver. In this case it is HTTP. There is some error which results in the driver repeatedly trying to connect and locking the account for the credentials which are being used. Again this makes troubleshooting the driver.
So if there were some code I could add to the driver that would allow me to effectively stop\pause and start\resume the driver that would be exceedingly helpful.
If you're writing the driver, you have total control over what you might include to effectively disable at least the telnet portion. For example: you could have a custom command that you run (manually or schedule an app or have another automation, e.g., a physical or virtual button press, to do the same thing). The command could modify a state value you can use to track whether it's "disabled." Obviously this can't totally "disable" the driver itself, or you wouldn't have a way to automate the re-enabling with a similar command (nor can a driver truly do that to itself to the extent that it completely stops running/waking up; it's just a matter of how you choose to have the driver react when that happens).
The only way to totally disable the entire driver is to use Hubitat's built-in feature for manually disabling apps and drivers. The original intent of this feature was that you could use it if trying to troubleshoot a hub problem (like if you suspect runaway code causing slowdowns on the hub), but you can use it for whatever purpose you want. The tradeoff is that there is no way to automate this--you have to go into the admin UI and enable/disable yourself. If this is not a driver you're writing, this will likely be the easiest option. For how to do that, see here:
I'm not sure which of these options you'd actually want, but hopefully one of these suggestions helps.
That is also true, but it sounds like the original poster had a device installed using one of these drivers and needed it to be kept that way to troubleshoot the real-word device under a specific state.