As I mentioned though, nothing is free. If it has lots of latitude, then it becomes that much harder to create generic user interfaces and logic that will still work if you swap out a device. The device capabilities stuff (we call them 'device classes') really are for multiple things:
1. They allow you to create user logic that is portable. I.e. I could create a piece of logic that you could use pretty much as is, basically just indicating that you want it to apply to devices x, y, and z, and the configuration interface can present you only those devices that provide the correct interface.
2. They allow you to create really nice user interfaces that aren't just remote controls on a screen, that are very activity oriented type things that non-technical house members can actually use, but which have a reasonable chance of being re-applicable to other systems (a big deal both for professional installers and for creating any sort of 'economy' of third parties able to create reusable tools for customers of the system.)
3. They allow you to swap out devices and not have your carefully constructed world come crumbing completely down and require days or weeks to adjust.
Almost all of those fall over to some degree in the face of even a fairly small amount of 'flexibility' in the defined device classes. Dealing with all of the combinatorial variations gets really complex, and difficult to test and maintain over time. And display mechanisms or logic hosting mechanisms may not have the dynamic capabilities required to adjust on the fly, i.e. they have to be created with a set of known capabilities for the most part, maybe some amount of adjustment is possible. So, generally speaking, lots of optional bits in the device capabilities actually pushes folks more towards the 'remote control on a screen' scenario, because that's the only one that's reasonably adaptable enough to deal with lots of optional bits and pieces. Just find out what's there and present it all in a one button does one thing sort of way.
Very strict definitions, OTOH, allow for all of that, but they will mean that various devices can't meet the test and therefore can't be supported (at least under this standard scheme.) Or it means that lots of functionality of some devices are only available outside of this scheme, which for most folks will mean not available at all in any nicely integrated way if they depend on the auto-generation capabilities.
Our system has a lot of device classes which are very strictly defined and pretty complete. It allows for all of the three scenarios above, but it does often run into devices it can't support because they are just so off the beaten path or not good enough. We don't allow for hardly any optional functionalty. Where we do it's not optional features per se, it's thing like we don't strictly define the arming modes for a security system, we just make them available via the driver to present to the user in some way, and the first one always has to be Off to represent disarmed, fairly small things like that. We do allow 'out of band' functionality, but it's only available in the 'old fashioned' way of actually creating logic and interfaces by hand and dealing with device specific stuff. How does Homekit allow for such out of band functionality, or does it?
And we also don't strictly define 'device types', some are more fractional than that, and drivers can implement more than one device class. For instance Volume just allows for volume control (get/set the volume, get/set the mute state, adjust the volume up or down.) So if you have some logic or user interface component that controls volume, it doesn't have to understand all of the possible types of devices that might provide volume control, it can work with any device that implements the volume device class, and a device can present multiple instances of any particular device class (e.g. a multi-zone audio system will be multiple instances of the Volume, Switcher, and InputSource device classes, usually, there is no separate multi-zone audio device class at least not currently though there could be some bits that could be associated with such a class.)
So we have a fairly nice set of definitions, and can use that to auto-generate a pretty nice set of touch screen interfaces. Though, it still requires a good bit of configuration on the part of the user, to tell us what rooms he has and what devices are in each room, to provide user readable labels for things for visual presentation, to provide some special actions that might need to be run in a given room when the user invokes one of the supported activities (and of course we can only support a set of pre-defined activities because anything more would require some crazy level of artificial intelligence.) Definitely it allows for generic logic and device swappages with fairly minimal to no impact.
And it still can't do lots of 'activity oriented' type stuff that would be nice to do, because there's just not enough information available even after all of that. Even to provide some customization of the auto-generated stuff requires that they understand how to create user logic, and to do anything really useful that usually requires understanding conditional statements which goes over many people's heads.
BTW, I would say that, if devices are required to cough up their capabilities, that will mean that vast numbers of devices will not be supportable because they have no means to do so, and would require significant redesign to provide that info. In a central controller based system like CQC, that's not necessary. The driver that provides access to the device can provide that information, so it allows for the same sort of 'introspection' or whatever you want to call it, without requiring the whole world to re-design themselves to comply to a particular scheme. Ultimately, that's going to be a huge problem for any system like Homekit which is oriented towards the devices themselves being cooperating nodes in a higher level framework. Yeh, you can 'bridge them in' in some way, but then you are basically doing exactly what everyone else is doing, except it's even more complicated because it's two different worlds being jammed together.
BTW, I'd imagine the typical Crestron installation is probably a good bit lower than that, if we are talking about averages and talking about homes (i.e. leaving out corporate/government installations where cost isn't so much of an issue.) They do sell less expensive controllers these days.
