I think this is also my plan. It's clear that in seeking official certification (which I absolutely think they should do) the lack of support for LAN devices and custom virtual drivers means a proudly unofficial method is still very much required!
I'll only be moving the basics, and only to reduce the potential points of failure and questions like "why's the light not working" at the exact moment I needed to reboot the computer running Homebridge. 
The funkier stuff, such as my "Virtual Switchable Presence" thing, will solidly remain Homebridge. Interestingly, I see that no devices through the official integration support presence, which on HomeKit is solidly a "people thing", whereas on Hubitat it's used to denote the presence of a device or a person (depending on the purpose of that device). I guess "presence" may be another protected term in HomeKit.
From the docs:
Most Z-Wave and Zigbee devices are supported. Devices that are not supported (per Apple restrictions for HomeKit bridges) include:
- locks and garage door openers
- LAN, Wi-Fi, or cloud devices
- User (custom) virtual drivers
I'd be interested to know why the custom virtual drivers are off the table, while the built-in virtual devices appear to be okay. I'd also be interested to know how they're differentiating devices on the hub, because looking at what appears and doesn't in my list, they nailed it. 
Huh, also - is HSM supported in the official HomeKit thing?
EDIT: Nope, no HSM in the official integration. Well, there's the clincher!
EDIT2: Ah, devices brought into HE through things like CoCoHue can also not be passed on to HomeKit through the official integration. I use some non-Hue lamps with my Hue hub, which (for reasons of corporate greed) don't get passed to HomeKit through the official Hue<>HomeKit integration either. Using Homebridge and CoCoHue they work just fine.
