I honestly don't know if Option #2 would support DSC, but from glancing at this thread I'm going to guess no.
I don't want to speak for @doug, but I believe his beef was with the Hubitat platform and the (still plaguing many) issue about hub slowness. I don't think there were any huge concerns with this integration, however, I cannot speak for if this integration may have caused his device to experience the sluggishness that caused him to leave. I do know people who don't run this still have sluggish devices. I do know that the native integration uses telnet and that the Envisalink device is super-chatty with it's communication.
My biggest concern at this time is getting as much processing as possible off of the Hubitat device itself and leave it to handle zwave, zigbee devices, run a few custom (but not resource-intensive apps). I don't consider Option #2 to be resource intensive and run this on my primary hub today. The other apps I run are things that interface directly with local services (some running on docker where the docker image is handling the heavy lifting) (Neosmart, Honeywell Option #2, Camect, Raincloud, Garage Doors Controller (ripped out MyQ Lite and my system got MUCH more responsive!)). The thought is to keep as much stuff off of the Hubitat device itself, but still keep it local (on my LAN). I'm also in the middle of moving many of my Rule Machine rules to Node-red to further compartmentalize things as to not impact CPU/Memory of the hub. It boggles my mind why Hubitat is continuing to release new devices with no apparent performance/rule processing upgrades. If there was a "pro" box or docker option, I'd keep everything there.
I think @doug had similar issues and went to go use Home Assistant. I like Hubitat and am more comfortable in Groovy, so I'm staying here. It also meets WAF much more so than HA.
Welcome to the club, hopefully I helped and haven't scared you away 
