Configuration Management was a key architectural improvement in Drupal 8. Gone were the days of shipping giant mysqldump files between developers and writing hook_updates to perform simple config updates. Instead we got drush config-import and config-export, so now we ship giant directories full of YAML files between developers and write hook_updates to import updated config without clobbering production values.
At Consensus, one significant challenge we noticed with the new D8 config management system is the issue we call "config drift": if you make changes to a config YAML in your dev environment, what happens when you deploy that into a site with a different config? What if you only wanted to update one value in a config entity, but someone has changed a different value from the same config object in production?
Config Enforce was borne of the idea that we could avoid the problem of "config drift" in production by enforcing config values, preventing them from being changed in the production environment at all, so that deployments become trivial.
Instead, Config Enforce collects "enforced" config in target modules from the development environment. This creates a natural development workflow where config that's relevant to your site (eg. changed from defaults) is automatically captured on disk, along with its dependencies, organized logically (similar to Features modules of old) instead of a single giant directory with every config entity in Drupal's active storage.
