The actual usefulness of this technology is more open to debate. Some claim that the only time the technology is of good use is during the initial OS install and subsequent application install, all of which happen only once. In general life most files are already compressed either before save by their application or by their very nature (eg MP3).
OTOH, email (depending on client/format), web cache, logs, and most common document formats, are not natively compressed, but are highly compressible, and this ends up also including much of what goes into your pagefile. Also, things like MP3s will tend to be WORM, just like OS installs, and thus will be causing hundreds to thousands of times less wear than even small host writes.
IMO, compressible performance should be considered as a bonus, like extra performance from TRIM. Even with compressible data, you can't verify, without testing your own application or set of applications, how much benefit compression can give you.
In addition, WA is low enough that 99% of desktop users will see either device obsolescence or a failure mode other than flash wearing out. So while the <1 potential WA might be nice, is mostly a good feature for future NAND with even lower minimum write cycle specs.
As a bit of a tangent, I'd personally like to see a dedicated write unit, capacitor-backed, with its own RAM, on the controllers, so that on power loss all pending writes to a coherent state could be flushed, but not require keeping the whole thing powered, and at the same time, allow lazy writing, for performance and wear, while power is stable.