I agree with lots of that. I find the driver situation to be not that satisfying as a user, but manageable as a long time user. And I think it adds complexity that Hubitat then has to manage.
I'm not a fan of "basic" drivers as they by definition leave something out. Perhaps the best example is Hue. For a long time, years, the built in integration was basic. There were 2 more complete integrations. The basic became inadequate long ago with any Hue complexity. Hubitat finally fixed the issue by more or less making CoCoHue the built-in driver.
The situation makes it hard for new users & sometime experienced users to know what to do. A couple more examples: 1) Third Reality plugs have configurable power recovery settings. The built in driver does not. So users are forced to find and use a community driver from a developer that isn't using Hubitat any more. (To its credit Third Reality marketing material notes that Hubitat doesn't support the feature.) 2) The Zooz drivers. Everyone relies on 1 non-employee to make the devices work as expected, with often more capabilities than the Hubitat "basic" drivers. Not to mention support of those drivers.
If it were my company I'd put in regular reviews of built-in device drivers. Identify & prioritize improvements/feature additions. I'd also develop an official developer program and invite the more professional devs to be part of it. I'd develop some sort of "Hubitat seal of approval" for the drivers developed by those devs. Maybe kind of similar to Home Assistant where vetted projects get to be part of the core platform where they now have different certification/quality ranks. The non-officially sanctioned drivers get added via the HACS (similar to HPM).
Finally, one more from the peanut gallery, one of my higher interest drivers to be taken into "official" land would be ESPHome. There are some cool projects out there. The community driver doesn't support encryption due to platform limitations I believe. And the developer doesn't use Hubitat anymore.
