One way to solve this is to pair all of your switches with HE rather than with Hue and use Hue just to control bulbs and similar devices. That way polling becomes irrelevant.
I have three Hue hubs and the only thing I have paired to them is bulbs, light strips, etc., and Hue HDMI sync boxes. I only push commands to Hue devices - I don't go the other direction.
Ugh, don't I just know it... but my problem is that this was a new build house and everything is hidden away behind spots and switches.
I just can't get my head around pulling them all out - there are 50+ Samotech 308 and 309 units around the house. When I initially paired them it was because my wife likes using the Hue app, plus at that point it was the only hub that I had (I didn't want to turn my ST hub back on as I knew I was leaving for Hubitat at that stage).
I've tried increasing readTimeout and still see random disconnects coming in from the eventstream interface, sometimes a couple a minute, sometimes every few minutes, sometimes longer without anything, and this value doesn't seem to have any effect as far as I can see in the user logs. Not sure if the engineering logs paint a better picture.
Is the Hubitat eventstream interface experimental? 
I've labeled it that way in CoCoHue because the v2 API (which it is tied with) is not finished and was not fully documented when I started, but I'm not sure if there is anything I could be doing that would be causing seemingly spurious "disconnect" messages (besides playing with readTimeout, which doesn't seem to be it--and I say "seemingly" because it doesn't actually seem to be disconnected in that messages continue to come through).
For the OP, I see you've got some good ideas already, but another CoCoHue-specific thing you could try if you keep eventstream enabled is to lower your polling frequency. Theoretically, only the former should be needed, but I noticed some things didn't come through on the eventstream last time I checked (which a poll did catch), and in case one of the disconnects is real, it may be nice to have as a backup. Enabling logging on the bridge device and probably the app would also give a better picture of what methods are actually running this often (that would be more for me to see if you want to provide more information--probably won't help you much in terms of things you can change). Polling, of course, will run on whatever schedule is set, but eventstream will wake the driver every time something comes in, so I suppose that sometimes could produce on-paper worse statistics (though whether that could actually cause hub load problems, I don't know...).
Many thanks.
I've switched off polling and turned the event stream facility back on. Will monitor and report back 
Alas, maybe I spoke too soon. CoCo Hue still dominating Device resources even with polling switched off... Guess it's just a matter of time before I get another alert?
Less than 3% of total runtime shouldn't be an issue unless it all happens in the same instant, so don't abandon hope just yet.
Looking at my (production) hub, the Bridge is at about 1.3% of total for me, so similar but just a tad less, and I haven't noticed any problems. (I don't think percent of busy is as good of an indicator because it depends on what your hub is actually doing, but mine is even higher than yours FWIW.)
I suspect that some of this is coming from the driver waking when the eventstream reports a (usually false) disconnect, but actual events from your lights, groups, or sensors would also do it. It's possible that more aggressive polling would actually fare better stats-wise than the eventstream, but I'm not sure that either of these values is high enough to truly be a problem. Debug logging, as in a few posts above, would at least show you most of the reasons it's waking.
If Hubitat can see something in the engineering logs that suggest a specific problem, I'm open to ideas. The one thing they've suggested in the past is increasing readTimeout on the eventstream connection. In the current Bridge driver, this looks like line 60. Wherever it is, you could change readTimeout: 60, to something like readTimeout: 3600, to see if that helps, though in my case it didn't change much. I never released this change for that reason but will probably do it then next time I update, anyway.
Thanks again @bertabcd1234 will continue to monitor, and test turning off the eventstream for polling should I see negative effects. I won't change the readTimeout level just yet, but will probably try your other suggestions first. Current hub stats below seem to be holding out:
Don't get sidetracked by what didn't happen, yet. You came down from 11.5% busy to just 3.8%. If you don't have any performance issues and don't see alerts, stop troubleshooting for now and come back at it later if it happens again.
Thank you, yes I will do...
Can I also just say, it's absolutely bloomin' fantastic to get this type of direct support from the devs and founders. This is why I switched from ST and I am more than happy to pay for Hub Protect and Remote Admin to support the business. Don't ever change. 
Download the Hubitat app
