Note that checking anything in userspace on a compromised machine does not actually prove that the machine is not compromised. It is very easy to boot insecurely and then make everything lie that the boot was secure.
Assuming they're USB devices they shouldn't be a reason to do this... Apple moved third-party drivers for USB devices and audio HAL extensions to user space, so there's some minor overhead choosing DriverKit over IOKit. Everything I've dug up says it's low single digit percentages. I wouldn't be developing USB drivers against IOKit anymore personally and I'd be looking to move over pretty aggressively before Apple drops the hammer.
Not exactly, distribution conversation aside this is specific to kernel extensions. Apple's been moving drivers out of kernel space and into user space for several years [1]. There's a lot of good reasons for doing so, and not a lot of drawbacks. I'd consider this to be a strongly worded API deprecation notice.
You can run unverified code if you build it yourself. You can distribute unverified code by just paying $99/year to Apple. Not great, but still no need for specific code approval.
Not if you want to use some features like bridged networking. For that you need to go and beg Apple for an entitlement. Or you have to disable SIP entirely.
Readit News
https://help.uaudio.com/hc/en-us/articles/360057137692-Apple...
[1] https://developer.apple.com/documentation/driverkit