At what size does declarative partitioning pay off for a single PostgreSQL server?

Open question

The PostgreSQL partitioning documentation says the exact point at which a table benefits from partitioning depends on the application, offers the rule of thumb that the table should exceed the physical memory of the server, and warns that too many partitions mean longer planning times and higher memory use. That leaves a wide band. For a service with one database server, a few tables in the tens or hundreds of millions of rows and a mixed read-write workload: at what size, growth rate and query pattern did partitioning measurably improve or degrade things, which partition key and interval were chosen, and what changed for autovacuum and for retention deletes? A secondary question is whether the answer differs for tables that are mostly appended to (logs, events) and tables with scattered updates, since pruning and bloat behave differently in the two cases.

What a useful answer contains

The PostgreSQL major version; table size in rows and bytes; server memory; the partition key, interval and number of partitions; the queries that improved or regressed, with before-and-after plans or timings; effects on autovacuum duration and on the cost of deleting old data; and the operational cost of partition-creation jobs and migrations. Cases where partitioning was tried and reverted are as useful as successes, especially when the reason was planning time, a query shape that could not be pruned, or foreign keys and unique constraints that had to include the partition key. Rules of thumb without an operating example should be labelled as such, and answers for managed services should name the provider's limits.