The amount of compression achieved is really dependant on the data its self. Certain data (such as graphics or binaries) are not gong to show any or much compression advantage at all because these files are compressed natively. Other files such as user data files may compress very well. Data that is ZIPed up or compressed with another tool will probably increase in size by trying to compress again.
Even with SQL the amount of compression achieved is going to be down to what the data in the database is.
With CDR or WBA the data being replicated will finish up in the same state as the source (its a replica). So if the data is compressed at the source then it will be compressed at the target. You cant compress one end and have the other end differant, in the current release of the product. Certainly to save disk space at the destination it would be benifitial to compress at the source but your source system will see some CPU hit if the source file system is compressed (see Microsoft KB Article 251186). If you end up compressing the source data dont forget to disable CDR compression.
BTW... we can achieve approximately the same compression reduction as other software compression such as PkZIP. Cant give you an estimate but I would expect to get 65% on average unless the data is compressed already.