Thanks! Howard is such a legend 
This is particularly chilling…
where it reveals that “CloudKit can enforce throttles when it deems necessary on any app or service that uses the CloudKit framework, CloudKit Web Services, CloudKit JS, NSPersistentCloudKitContainer, and NSUbiquitousKeyValueStore.”
Key points I see in this quote…
can: May not but is certainly capable. I wouldn’t bet on maybe not.
when it deems necessary: i.e., outside our control or desires.
any app or service: again, discretion is absolutely App’s.
To anyone reading this, this is again not us ‘passing the buck’ or finger-pointing. It clearly shows how much of the sync situation with CloudKit is not under our control. Reread that quote (and the whole article is worth reading) and let it sink in.
Came here to post this, though the quote that caught my eye was this one:
It’s clear that apps and other software that could issue multiple requests of CloudKit over a short period, or could trigger a pattern of requests that iCloud doesn’t like, could be responsible for situations in which syncing of shared data with iCloud is put on hold. Unless the client app responds appropriately to that throttling, you could be advised incorrectly that iCloud isn’t available, or worse still the sync could simply fail silently.
The tech note Howard mentioned:
Hah, that Eclectic Light post got immediately bookmarked in one of my DevonThink libraries!
The part of the post that stuck out to me was this:
Perhaps the worst approach the user could then try is one of the solutions most commonly recommended: turning iCloud off and back on again, as it has no effect on the retry interval, and could trigger further throttling.
Indeed, when I’ve sometimes had iCould sync issues in the past, I’ve done just this (on recommendations from various sites), typically to no avail. Now I know why it failed.
Sort of!
Glad you’re better informed now too!