In general I think the best opportunity would be to extend the CLI, perhaps together.
About your questions:
Exported content from on-premise squidex cannot be correctly imported to cloud.
Why is that? It is a very general statement.
Assets synchronisation does not include metadata and therefore assets are invalid.
What kind of metadata do you mean? All metadata can be changed later. So part of your sync process should be upload of the asset as well as the change of the metadata in a later process. Some metadata.
Referential integrity between content is not preserved due to dynamically assigned IDs
Thats not true anymore. Most API endpoints do have an optional ID parameter now that can be used to assign a custom ID. But I have to admin that the auto-generated OpenAPI endpoint is probably not up to date at the moment. I will have a look into that.
Some content is not uploaded at all and does not throw any error.
It is a very general statement. If this would be the case, it would be a very big and crucial app and I have my doubts that this is the case, right now. If you are correct it needs to be solved, but perhaps it is just a bug in your synchronizer?
Or is there a plan to enable backing up and restoring apps on cloud, or adding possibility to current synchronization tools to sync assets and content?
There are 2 problems with the restore tool:
It is not safe. Content is not validated and I think there is a change that you can break other apps if your backup contains invalid events. I am not sure about that, but to make it secure and safe to use for everybody is a big deal. The only option would be to use signing, so that a backup gets signed but a platform and you can only restore it if the key is correct, but this makes other scenarios difficult.
The restore tool creates a new app and after a few syncs the system would look like earth after a zombie apocalypse.
I am open for content and asset synchronization in the CLI, but we have to talk about the details and how to deal with conflicts.