Debug logging generally shows messages being received on the hub from the device. It is particularly useful when troubleshooting driver behavior, e.g., if you have a switch that you think should be reporting as on but the driver isn't parsing it into an event on the hub side. This could help you (or really, more likely the driver developer) figure out why. Some drivers also log when commands are sent from the hub, which I happen to find helpful, but not all drivers do this, especially older drivers (it seems to be mostly newer Z-Wave drivers).
Description text logging gets logged as the "info" level in "Logs," and it generally shows what events got generated by the driver: things like switch on/off, button presses, power/energy reports, color changes, etc.--basically what the "debug" messages actually got parsed into. For most users, this is generally the most helpful. But note that it does not show what commands were sent to the device, just how information that is (usually) received from the device got parsed into an event on Hubitat, if it did at all. If a switch is already on and you send an on() command, nothing will normally change, so you won't get an event (or an info log). This is generally the same information you can find historically on the "Events" page for a device, though the events page is authoritative and logging the descriptionText column from there (hence the name of this preference) is just a convention.
Debug logging is, by default (and convention) enabled when a device is installed and then disabled after 30 minutes. It can also be manually re-enabled from the preference and, again, will be automatically disabled after 30 minutes. Description text logging is enabled by default when a device is installed and remains as such until manually disabled. This is stock Hubitat driver behavior, and a convention for (IMHO) well-written user drivers, but keep in mind that custom code can do whatever it wants here, and you may find community developers who don't follow these conventions.
"Route and LQI logging" is not a standard feature of any built-in Hubitat drivers I know of. Is that community code?
In any case, back to the core of the question: we've been told that the impact of logging on your hub should be minimal. (They've written more on this, but a quick mention from staff that I found with a search is here: Sometimes rules not running - #9 by bravenel). If you see frequent log entries, you probably have a "chatty" device that could be a problem on your network regardless of whether logs are enabled (the fact that they aren't enabled might just hide it better). Device stats from the "Logs" page would be a better indicator of hub impact. Past logs are pruned after a certain size, and live logs only stay for as long as you have the page open, so impact there should also be minimal over time. (But cutting down on log entries may help you see more history, which can be helpful for troubleshooting things that happened in the past.)
It sounds like you're trying to figure out what app is acting on a device. Logs (or event history) for a device won't help with that--commands aren't events (though they may eventually cause an event to happen) and devices don't know which app sent a command. The best way to figure that out is probably to look at the "In use by" section on the device page and see what apps are there, then consider turning on logging for those apps (most apps have various logging options) if that alone isn't enough to figure out the behavior you see. A log from an app is going to be more helpful than a log from a device.
