There really isn’t any good rationale you can give to clients here, it’s just a design decision that Webflow’s technical team made to support the backup and restore process efficiently.
From what I can tell, any time a backup is made ( which happens a lot ), the CMS data is cloned and those cloned items get new ID’s so that they can be stored in the database alongside your regular CMS content. When you restore, the version you’re retrieving now has those new IDs.
Yes, there are other design architectures that could have resolved this, using a persistent ID, and a “current live project” indicator but this actually creates a lot of complications under the hood with refs & multi-refs, and it’s not clear that added complexity/fragility would benefit everyone.
Consider, let’s suppose ID’s were persistent across backup & restore. You have an API integration which uses your DB of products. Then you restore a backup because the client needs to revert a major UI design piece. Now you still have your same products DB with the same ID’s, but the content is several versions older. ID’s match but content is no longer in sync with your integration. Some items are missing. Other items exist, which were later deleted.
Is that better? I’m not sure.
Personally I’d prefer that the CMS and the Site were decoupled so that you could share a CMS across multiple sites, or use multiple different CMS’s in a single site. Then features like country lists, zip code lists, etc. could become library CMS resources. But that’s a complex path as well because you then put the burden on the “schema contract” between the CMS and the site. If you change the CMS structure, the sites using it are broken until they adjust for that change.
For most people, that added complexity isn’t beneficial.
If you want to put a positive spin on it, you could say “this approach ensures that your CMS data is backed up with each version as well, so you know it’s safe.”