As I've not been involved with CMI much, I'm not sure this has been discussed intensively already. If so feel free to close :-)
So with CMI, obviously the config is in files and database dumps won't work without the right config. While that's a direct consequence of the file-based configuration management system, it might have some not so obvious consequences to average users.
I mean, for a developer who is used to keep its config in version control, that's not a big deal. If you have an old dump, and it does not work with your config any more, you roll back and it works again. But wait - how do recover? You roll back and import your old config? Nope, you cannot import without having an active configuration for comparing in place afaik - so you'd actually have to violate the mantra of "do not touch the active config" and copy the staged config to your active config to make things working again. But worse - if you are not using version control you are basically screwed - or better said your dump is.
And this happens quicker as one might think. Consider you are dumping your database just to take a quick snapshot of the current content, then you are adding a field. Afterwards that small change you did not export to config yet, you want to revert to your content snapshot, but when you do you'll run into troubles. The database and your active config becomes out of sync - the config contains the newly created field, while the database does not know about the field and misses its table. I guess the site will throw quite some sql errors and the dump became disfunctionial.
Compared to Drupal 7 + features, where a db dump always contained the active config that's quite a change. Given that active config it was always possible to revert to the latest config/features, as there was a working state (database) to start over from. But with Drupal 8 a database dump alone is not a working snapshot of the site anymore, and might become disfunctional rather quickly.
To avoid any troubles in d8, you may *never* dump your database without keeping track or dumping the respective active config, such that you can restore it *with* the dump.
While that's not so problematic for people using Git or a similar VCS, even those could use some assistant tools that work like "drush sql-dump" & "drush sql-cli" before, i.e. drush really needs a dump and restore active config command I guess.
Moreover, I think that this might become an issue for not so technical users who are used to "taking snapshots" of their sites by dumping databases. Really that isn't enough any more, people will have to snapshot the database + the whole files directory or at least their active config.
As possible improvements I think we could
a) improve the tools (drush) and educate people very well, maybe improve the UI to offer a complete "site snapshot" (optionally covering files?) also.
b) rethink how active config is stored to avoid inconsistent states (again), i.e. move active config back to the db.... It's a step that seems like a step back and quite weird for a primarily file-based config system, but it wouldn't actually change much compared to now, solve the consistency problem and avoid the "do not hack your active config" mantra.