Should tiny dimension tables be considered for row or page compression on servers with ample CPU room?

An [old Microsoft paper](https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2008/dd894051(v=sql.100)?redirectedfrom=MSDN) says to consider using ROW compression by default if you have lots of CPU room (emphasis mine). > If row compression results in space savings and the system can accommodate a 10 percent increase in CPU usage, **all data should be row-compressed** Today, we have even more CPU space than we did back when the paper was written. [Wise men](https://youtu.be/tHfeCstrDAw?t=514) have said that we should consider using PAGE compression everywhere unless we have a compelling reason not to. This is all good advice and I often see sp_estimate_data_compression_savings agree. However, what should be done with tiny tables that are frequently accessed? For example, I have some extremely small dimension tables. 100 rows at most and very few columns. Because they are so small, the space-saving benefit from any compression is minimal. What is considered the best practice for applying ROW or PAGE compression to such tiny tables on boxes that have a huge amount of free CPU room? For the purposes of this question, ignore columnstore. We are only talking about old-school rowstore indexes on disk-based tables.