A persistent object cache changes what transients mean

Without a drop-in, a transient is two rows in wp_options. With one, transients are stored in the object cache and never touch the database — which is faster and changes their durability in a way that catches people.

set_transient( 'shop_brand_counts', $counts, HOUR_IN_SECONDS );

// no drop-in: survives a Redis restart, survives a deploy
// with a drop-in: gone on FLUSHALL, gone on a cache eviction

Anything relying on a transient still being there — a rate limit, a lock, a “we already sent this email” marker — becomes unreliable the day a persistent cache is installed, and installing one is usually presented as a pure performance change. The database is the right place for state that must persist; the cache is the right place for state that may be recomputed.