Sites can't be re-installed using core configuration management

A standard configuration management workflow looks, in part, like this:

1. Install a new site for the first time locally
2. Make any necessary customizations (adding content types, views, etc...)
3. Export the site configuration to disk to capture these customizations (either via drush config-export or the config UI)
4. In another environment (hosting, CI, etc...), install the site again
5. Import your site configuration to restore your customizations (drush config-import)

The point of this ticket are that these last two steps are impossible with Drupal out of the box. There are two primary problems here: first, that the site UUID will generally conflict with your configuration on disk and prevent imports, and second, that as part of the install process, a ton of default configuration is created by Drupal core and contrib modules which later has to be overridden.

The site UUID problem can be worked around in a few ways. If you are using Drush 8, you can use the --config-dir argument and it will overwrite the site UUID, but this has been deprecated in Drush 9. You can manually set the site UUID prior to the config import, but this obviously feels a little hacky. Finally, you can use an outdated core patch (described below).

The second problem is harder to work around. The biggest issue is that during the config import, Drupal has to delete and recreate a ton of configuration that was provided by default (especially since the UUIDs of individual configuration files will generally be different between config on disk and the db), and this triggers strange conflicts and core bugs that cause the import to fail.

Even if these conflicts and bugs were to be fixed, there's a more fundamental architectural problem here, which is that is just doesn't make sense for Drupal to be installing a ton of default configuration only to blow it all away during the subsequent config import. If nothing else, this is a major performance drag that can only really be worked around by installing the site directly from existing configuration. This was going to be implemented in #2788777: Allow a site-specific profile to be installed from existing config, but the direction of that ticket took a significant turn and now only allows a site to be installed from config owned by a profile (rather than config owned by a site, i.e. /config/default)