1) Yes, it is possible to access it from Liunx. As others explained, ntfs-3g is capable of handling compressed ntfs.
2) reliability: compression is in ntfs for a long time now (since Windows NT, see http://www.ntfs.com/ntfs-compressed.htm). I don't see any reliability problems on windows. I'm not that sure about non-windows implementations (e.g. linux). If your only concern is reading the data on linux, this is poses no reliability problem (mounting read-only is a good idea when restoring backups anyway).
Also data is compressed on cluster level which is usually 4 kiB. A physically corruption of the disk only affects single clusters, not entire files. In this regard compressed ntfs should be just as reliable as non-compressed.
3) Performance: The KB article you cite says performance might be affected on a server system, where the CPU is already saturated. On a desktop system with a current CPU as you describe it, using compressed ntfs for backups, should not have any significant performance impact. On the contrary, if you store compressible data, you might actually gain performance as you have less I/O. That is especially true, if the interface (USB 2.0) is slow compared to the CPU. I guess your CPU should easily be capable of saturating a USB 2.0 link writing or reading compressed ntfs.
4) If you set the compression flag for the entire filesystem you shouldn't have the problem of non-compressed moved files.
4NTFS never transfers files compressed, in either the windows or the Linux driver. That optimization doesn't exist, sadly. You'd have to go extremely low level to achieve that: Create the file and metadata, pre-allocate the space, then raw write the compressed data to the MFT and allocated clusters. So in normal use, you won't gain anything I/O-wise. – SilverbackNet – 2014-01-27T02:01:26.443