Very, very quickly (because I’m snowed):
-
iCloud has no problems syncing a folder or a package file or anything else. That’s not exactly the problem.
-
There are generally two types of app: shoebox apps such as Photos and iTunes (and Ulysses, for that matter) which have a single window that manages a single database of files, and document-based apps, which use a different window for each file, and whose files may be anywhere on your computer.
-
Shoebox apps provide a window on a large amount of data and just save, for instance, a main index file and the single file affected if you make any changes, without touching the other gigabytes of data in the database.
-
Document-based apps save the entire document every time there is a change. Document-based apps can use flat files or file packages. Either way, the way the technology is designed by Apple, when you make a change, the entire file or package is re-saved (although the OS uses some clever atomic saving to mitigate against data loss).
-
iCloud is, for the most part, built around these paradigms, and integrated into the frameworks based on these common uses. (Which isn’t to say it can’t be used in other ways, but whereas almost any programmer can get iCloud working for these use cases, you would need some serious experience in sync technologies on board to bend it to other purposes and be prepared for a major project.)
-
Scrivener, however, is a bit of a hybrid between these two app types. It uses macOS document-based technologies in order to present each project in its own window and manage a single .scriv file for each project. However, it overrides these technologies at quite a low level in order to support huge projects, since each project is akin go to a mini-shoebox app. It uses a file package (a folder that looks like a single file on any Mac Scrivener is installed), but it does not–unlike standard document-based apps–re-save the entire package every time you make a change to a project. It would be pretty awful, of course, if you have a gigabyte of PDF files in a project and have to wait ten minutes for all of that to be re-saved every time you make a change to a bit of text. Instead, Scrivener overrides all of the standard mechanisms so that it only saves files that have been changed inside the package and leaves everything else alone. Unlike other package/document-based apps, it also overrides all of the reading methods so that it only ever reads into memory files required right now. (The standard macOS mechanism is to read the entire file package into memory–but again, you don’t want Scrivener reading a gigabyte project into memory every time it opens.) This ensures that Scrivener can run fast with any size of project, and ensures stability. However, it means that it bypasses all of the standard mechanisms for iCloud support.
-
Shoebox apps can generally work fine with iCloud because if some files are synced and others are not, they can just show this and notify the user that such-and-such a file isn’t downloaded yet if they try to click on it.
-
Document-based apps generally work because the whole file (package or flat) is saved in one go, so the whole file (or package/folder) arrives as a single entity on other machines. The app can then simply reload the whole thing. (This is also made much simpler by usually only having a single editor showing a single piece of data such as a text document–unlike Scrivener with the many, many UI elements showing different pieces of data, such as the outline, current text, maybe another text, synopsis and so on.)
-
Scrivener agains falls between these, though. A project is a single thing, and a project cannot work reliably if not all of its data is synced. For instance, suppose you make changes to text A on computer one, then move to computer two. But the internet is down and you don’t notice that your changes haven’t synced. So you make changes to text A there, too. At this point, because iCloud (unlike Dropbox) doesn’t make conflicted copies, all the changes you make to text A on computer one are lost forever. And that’s a minor example. You could end up losing entire outlining structures.
-
And because Scrivener saves and loads piecemeal, that’s the way the data would arrive, and Scrivener would have no idea of when all the project data is available to run safely.
This didn’t turn out so quick. 
Anyway, that said:
-
It is perfectly safe to use iCloud Drive to share your projects between computers just as you use Dropbox. As with Dropbox, you just need to make sure that your projects are fully synced and closed on one computer before moving to another computer, and then make sure they are fully synced before opening them again. This is not as smooth or simple as the automatic iCloud sync that is possible with more standard document-based or shoebox-based apps, but it is the payoff for everything else that Scrivener can do.
-
I do have plans to make it so that our iOS version can open and desktop sync projects using iCloud Drive too, and I think I have a solution for this. However, it will take some care on the part of the user, and there is a lot of work involved on my end to get this working (I’ve been going back and forth with Apple over a solution for this for months, picking apart the technical details–the Apple engineer also points out how iCloud and the general frameworks aren’t designed around the sort of thing Scrivener does). So, this won’t see the light of day until sometime later on in 2018. It’s being investigated, though.
I hope that clarifies some of the thorny issues involved.
All the best,
Keith