Like Steve said the only disadvantage is if you are CPU bound, decompressing the pages when they move from the storage engine to the relation engine is where the CPU overhead comes into play.

row compression re-writes the data pages to a new format that allows for better utilization of space. smaller data allows for better use of pages so total read's and write's should go down as well as memory required as they are storing less pages.

if you want to see the stats on what compression is supposesed to do, just an estimate, you can run sp_estimate_data_compression_savings http://msdn.microsoft.com/en-us/library/cc280574.aspx.

Page compression inherits Row compression, but not the other way around.

but compression, page and/or row can be applied to "standard" tables, partitioned tables, "standard" indexes, and partitioned indexes differently.

Example:

Table Customer, with Clustered Index Customer_Clustered

you can page compress Customer, and row compress Customer_Clustered. I would take a look at the sp_estimate_data_compression_savings to figure out which route is best for you.

you need to maintain the indexes the same way, but do not need to maintain compressed pages any differently than you would regular pages.