The config system hardcodes a number of required "config system housekeeping" properties in ConfigEntities and their YAML representation - id, uuid, language, dependencies, status, maybe soon third_party_settings...
But since those "system" properties live in the same namespace than the set of "domain" properties of each ConfigEntity type, there's always a risk of name clashes. As long as D8 is in developpement, the config system simply claims some property names, and contrib ConfigEntities need to adapt by not using a domain property with the same name.
Once 8.0 is out, though, it will be very hard to add/rename "system" properties in ConfigEntityBase if the need arises in 8.1 or even in 9, because there is no way to be sure that this new property will not clash with an existing "domain" property in some config entity type somewhere. De facto, we're locked.
The fact that we are still adjusting some of those "system" properties at this point in the cycle (rename some, add others...) - because, well, CMI is complex and takes a long time to be done right - is IMO a clear sign that we can't really say for sure we won't need to adjust more stuff later on.
I feel stupid for not spotting that earlier :-/, since this is exactly the reason why Field API separates "Field API system" properties ($field->label, $field->required) and "field-type specific" settings ($field->settings['foo']) - so we can add new top level "system" properties at any point without fearing that some contrib / custom field type somewhere might have a "domain" setting with the same name.
Ideally, ConfigEntities should have separate spaces for "system" and "domain" properties - something like "header" & "payload", in a way...