Oh, astroturfing - welcome to the fun

#1 - "I couldn't cash in on the ZIP name, so I decided to cash in on the RAR name" - even though you have no association to RAR. And as Jibz said, ZIP is an open standard (as well as being an ubiquitous term), you can't compare the two. Did it ever occur to you that you could have come up with an original product/brand name?
#2 - I might actually take a look at your product. Rather think it could be funny ripping it apart. Who knows, I might be surprised, but I have my doubts.
#3 - it's hardly rocket science composing a list of files that are unsafe to enable NTFS compression for.
#4 - why would I go through shell code to apply NTFS compression to files? Oh sure, there's some potential load balancing (CPU as well as disk I/O) that can help with speed. But why would I bother with "finishing threads at the same time"? Where does "safely" enter the picture, considering compression is handled at a very low level of NTFS? Fire up a bunch of threads, feed threads producer/consumer style, do DeviceIoControl(FSCTL_SET_COMPRESSION). Possibly apply some balancing. Magic? Hardly. Still using bog-standard NTFS features that have been with us since forever. If you were doing anything but that, you'd be listing patent numbers on your website.
#5 - (Stoic Joker's point, not mine) - date base compression. Yes, the disk clenaup utility, just like he said - it will offer to compress old files, based on... whoa... date. That's the way "normal users" would come in contact with NTFS compression.
#6 - (Vlastimil's point, not mine) "no sense" - I'm pretty sure his point is files that aren't compressible, not files that are dangerous to compress (hibernation and the core loader files read by the NTFS minidriver which doesn't support compression). If you just go gung-ho on the filesystem, you waste a lot of CPU time processing incompressible or very-little-comrpessible files, along with possibly adding massive fragmentation overhead.
#7 - <flame>I'm pretty sure I briefly used an archiver back in the Win9x days that was implemented through shell namespace, but who cares? Normal users have their zip folders, the rest of use proper standalone apps that Don't Suck(TM).</flame>
#8 - no, the sandforce controllers compress at the block level - this affects read and write speed, as well as reduce the free space available for wear levelling. And even for non-compressing SSD chipsets, the fragmentation (often) caused by NTFS compression will have negative effects on the block erases and writes. I sure as hell wouldn't NTFS compress anything but read-only data on any of my SSDs. As for avoiding sandforce, whatever - even Intel uses them now. And all SSD manufacturers have had their flakes-outs, that's just how it is with that technology at the moment.
#9 - except for the same "ZOMG WE ARE REVOLUTIONARY (but no content)" kind of marketing.
#10 - I have nothing to do with your competition. Or well, I don't think so, I honestly have no idea who they are. (I'm a regular user of 7-zip and the WinRAR, that's as far as 'affiliations' go - and I
hate snake-oil and marketing that cashes in on other people's work, but that's a general personal trait of mine.)
(Yeah, I'm grumpy, and neither my caffeine deficiency nor your tone helped.)