I'm using Windows 10.
When you first install Windows, local kernel debugging (windbg -kl) is disabled by default. To enable it, you must run bcdedit -debug on and reboot. (Though, as far as I can tell, Sysinternals LiveKd seems to work fine even when local kernel debugging is disabled.)
Why is local kernel debugging disabled by default? Is there any disadvantage to leaving it always enabled?
As noted in the comments, kernel debugging is disabled by default because it allows (even on 64-bit Windows) loading not-really-signed (self-signed) kernel drivers. (And disabling PatchGuard, etc.)
The comment about "an admin still lives in userland" is nonsense, of course. Commenter should go ahead and read Raymond Chen's posts about "being on the other side of this airtight hatchway". Allow me to use his words:
I think you know how this story ends. If you have administrator privileges, then you are already on the other side of the airtight hatchway. That you can use administrator privileges to pwn the machine is not interesting, because by virtue of being an administrator you already pwn the machine.
There is formally a distinction between Administrator and SYSTEM, seeing as they are some things which are ACL'd so that SYSTEM can do them and not arbitrary adminitrators, but that distinction is formal and not practical. An administrator who wanted to get some code running as SYSTEM could install a service that runs as SYSTEM. Or use Debug Privilege to take over a process (say, a service) running as SYSTEM. Or simply open a command prompt as SYSTEM and go to town. No need to go through the complex operation Q to get SYSTEM access.
The first sentence holds if you replace SYSTEM with kernel-mode driver.
You were right in your deleted comment that an administrator can load drivers, but on x64 they have to be signed.
What being able to load unsigned driver saves you is not 75 USD or filling an online form, but rather providing a provable identity. A kernel-mode code signing certificate is not the same as a domain-validated SSL certificate.
Note that Microsoft intends to require kernel mode drivers to be WHQL-certified (or use "attestation signing", supposedly only on non-Server SKUs), which requires submitting the drivers to Microsoft, and opening a Windows Hardware Developer account using an EV certificate. Hey! What's up with that? Is this a conspiracy colluded with CAs to make us pay more for certificates? Maybe. And maybe they want to be sure of your identity and are delegating the verification to the CAs (assuming that EV does what it's supposed to do).
Security-wise, this does not establish a real security boundary, but rather a mild mitigation. But there are other considerations: Microsoft doesn't want software publishers to install lousy drivers that take Windows down with them; and, if they happen to do it, Microsoft wants to know who wrote these drivers. That's the rationale behind attestation signing.
If you could easily enable kernel debugging, you can bet that some second-rate ISV would write lousy driver, without bothering to test or sign it, and would install it using that hack. (Actually, I know today of not-so-lousy ISVs that sign their drivers but don't WHQL-certify them, and use hacks to install them without any prompt. This is a real thing.)
Of course, the same lousy ISV can enable kernel debugging in its installer (which runs elevated), and can have its driver load after the next restart. But there's this annoying message on the desktop saying you're running in test signing mode to protect you from that. Sure, the same lousy ISV can hack around and hide the message, but at this point it may be easier to just get the certificate. This doesn't prevent anything, but it provides a mitigation by making it annoying enough so they won't bother.
If you wonder why enabling kernel debugging puts you in test signing mode, the answer is: Because that's the usual and intended scenario. There's a registry value you can change to require production signing even when kernel debugging, but that's the exceptional case. The default is correct for the common scenario. You have LiveKD. There's no reason for Microsoft to bend over backwards to deal with a scenario that doesn't really happen. They've got enough problems as it is. Like fixing all those crashes in Microsoft Edge.