> though it's probably not the first one would think of
Yep. The model makes sense when you have large databases (for us, it's hundreds of billions of rows in multi-DB Postgres instances) that have to directly serve complex read queries to millions of users pulling reports.
1) When you have users who access arbitrary reports over and over (for us, financial reports that don't change during the day), doing a simple `select *` from the cached report tables per user, where they can be thrown away at any time based on a TTL or other conditions, can be way faster and cheaper than creating and maintaining read replicas of slow-ish multi-TB databases to directly serve large volumes of concurrent queries.
2) Easy traffic control and queuing when you have large volumes of read requests coming through. This can be beneficial to large DBs serving reports to users irrespective of the kind of reports. In addition, when there is big, unexpected surge in user traffic, the reads just get queued and users just have to wait for longer to see the results, but the big databases never get overloaded.