I agree that row and page compression is a wonderful tool and I've been very successful in using it properly. I also agree that it's wonderful for the normally largest tables in most databases (audit/log/history tables, etc), especially since the usually fall into the W.O.R.M. category.
In the past, you've stated that people should just automatically use at least row compression on every table. You not said that in is the recent post but you have said that the OP should "be using it if at all possible" without stating what that means.
You also not mentioned the much longer times (2x-4x has been my experience) that index maintenance will take if you do need to rebuild compressed indexes nor the massive increase in page splits that can occur if the table suffers Null-to-Populated updates on what used to be fixed width columns... and it only takes one such column to cause the problem. Yep... you can help prevent that, in some cases, by lowering the Fill Factor but then you've just started "wasting" memory again. Of course that's still better than the doubling the memory requirements if you don't fix the page splits.
Again, yes... used properly on the proper tables with the proper insert patterns can save a huge wad of both disk space and memory. Used on the wrong tables, the resulting page splits that occur will be much worse than too little memory.