Like SQL Server's row-level and page-level compression, you get more rows per page, so need to read less pages to process the query. From cold this means less disk or network IO loading the pages from storage into RAM, and it means you can fit more into RAM (and potentially CPU cache when spinning over small enough chunks of data) so you can do the same with less RAM or reduce IO so be faster with the same RAM allocation (as pages will not need to be evicted as often to make room for others).

The trade-off is a bit of CPU time, every time the page is referenced. Not just when it is updated or read from storage, but potentially every time it is accessed, even just reading, as the pages held in RAM are in the same format as on disk so the decompression needs to happen on read also (unless postgres keeps a cache of pre-decompressed pages to help with this but my gut suggests that would not be worth the complication - where it would help significantly you would just not use this technique anyway).

In a great many scenarios, I would say most, this trade-off is worth it because of the relative cost of IO and CPU time needed to save some of it.

It might be significantly detrimental to performance in situations where enough of your data fits into RAM anyway and you are performing CPU-heavy analysis upon it.

Side benefits include reducing the size of your backups and reducing the time needed to take them, so there are other potential infrastructure and administration savings to be had too.