The original source for the article is a bit clearer on what's actually happening, and the blog post for the HN link omits some details:
I recommend read the original (and that the submission be changed to the original source instead), but a more accurate description here is that two Macs running two different versions of macOS will see the file differently once it's copied to iCloud. If a High Sierra Mac sends a file with a custom icon, for example, to iCloud, the High Sierra Mac will see the file as expected in iCloud. If a Mac on Sierra looks at the same file on the same iCloud share, it will see the base file without the custom icon. Other xattr items are removed as well, as documented in the original source.
This title sounds like the actual files get modified by iCloud. This is not the case. Only external data ('extended attributes') in the filesystem gets stripped. It is true though that this is called metadata, but so is EXIF in photos, or OCR text in PDF scans, which definitely do not get stripped.
Also note extended attributes do not survive most file transfers.
It's tough not to scoff. In years past it was a relief to see iCloud Drive/Mobile Me didn't simply strip out an entire directory. It was honestly a relief when Dropbox came along as at least you felt you could recover with their 30 day retention.
There must be mid-tier oldies like me who stopped using iCloud Drive due to those early loss of trust issues?
Although I haven't used this feature, the behaviour with the custom icon and filesize seems extremely unusual and I'd be quite puzzled if I came across this without knowing about it first --- imagine opening a text file whose size is shown as 500KB+, but discovering it has a tiny fraction of that --- I'd probably be shocked and, if it was a file someone else gave me, wondering "where's the rest of the data? Is my filesystem corrupt?"
Of course, if it doesn't count xattr sizes, it would be equally confusing in the other direction. Maybe showing "1372 bytes (and xxxxxx bytes extended attributes)" would've been better.
But from past experiences, IMHO xattrs and similar "bonus filesystem features" are not something you should rely on in general for portable data exchange. The name (or a slightly modified variant thereof) and the associated sequence of bytes are all that can really be relied upon to reliably survive transfers, since it's the lowest-common-denominator abstraction.
PDF has annotation features in the file format itself; perhaps Skim should use those instead --- in which case annotations will also survive and be visible in a Windows or Android PDF reader.
I'd also consider things like icons to be "display metadata", in the same way as the size of the icon or its position in the GUI use to display it.
Slightly Off Topic Question.
Why is Apple continuously pushing its customers towards cloud, when many ( more then 40% ) in developed world dont even have access to 10Mbps + Internet Connection. ( And that is just download speed )
I wonder if the OP and the article linked in one of the other comments looked at whether or not the Sierra install was on APFS or not. High Sierra automatically converts all drives to APFS during install while Sierra does not. Since Sierra stores xattrs in a special B*-tree node rather than as extended filesystem attributes, it's possible that the High Sierra install is saving them to iCloud Drive properly with all the filesystem attributes and the Sierra install is dropping them, for security reasons, as they would have been invalid on an HFS+ filesystem.
That should be viewed as a bug from the user-perspective but, because those extended attributes literally did not exist when Sierra was released, it's hard to say that it should be considered a bug for Apple when it's functioning exactly as intended in terms of the filesystem. It's almost like complaining when MS-DOS saved files as NAMEOF~1.DOC instead of "Name of Really Long File.doc" from Windows 95.
Unrelated, but IMO, the clients for iCloud Drive on both iOS and OS X are very poorly implemented. I used to have a 16 GB of iPhone that would magically go from 8GB of available storage to 0 despite me not downloading anything onto it. It turns out, if you have iCloud Drive enabled on iOS, it automatically downloads the entire content of your drive to your phone and in the settings app, it classifies it under the "other" so there was no way for me to figure out what was eating up all of my phone's storage.
The mac client isn't any better, it sometimes utilizes 100% of CPU to sync a few files (bird process on OS X) with iCloud and there's no way of stopping the sync or slowing it down.
Not related, but when I adjust chmod for files in iCloud, they revert back (during next sync cycle I presume). Just something that may or may not be interesting for folks looking at iCloud.
I wonder if its a security precaution.