The base WordPress transient functionality (get/set transient functions) will in simple cases save all transients in the options table. On a base install of WordPress.
But each function first checks whether an object cache is hooked up.
With a line like
if ( wp_using_ext_object_cache() ) {
$value = wp_cache_get( $transient, 'transient' );
WP checks for an external object cache, and then completely bypasses all the normal code to look for transients in the options table. Mapping transient functions to wp_cache_get/set functions instead.
If you are finding the transients in your options table, it must be because you have not hooked up object cache functionality to speed up your site. Some plugins (including those I build myself) also use similar checks on availability of various caching systems to on their own completely bypass WP’s transient system, and go “Object Cache” all the way so to speak..
My current sites for example make heavy use of APCu to keep all that temporary and “must find quickly” data in shared memory. Saving away the expensive database queries (and their network connections) entirely. I also on some sites build page portions with their own caching, so for example header and footer page sections and some widgets do not have to be rebuilt on each new page/post call, since they are common to and independent from page/post content. Smart themes should do something similar.
Hence my view that if a plugin is really cache cognizant, it should handle it on its own. If it uses WordPress’ transient system, like most do, then the WordPress core should handle cleanup. The plugin developer should not go querying the options tables for stale data that may or may not exist. Or at least thats my thinking.
Note, though, that using the options table (or generally a non-transient cache) does have one advantage.. If someone is saving longer term transients (day, week, month) the options table is a stable place to stick things. It maintains data across Apache and/or server reboots.
Anything you place in for example APCu Object Cache is dead if the cache functionality is restarted, as it is in-memory only. So, using caches, one does have to think a little about what type of data is stored where. ??
I for example store even page caches in memory based Object Cache, rather than on the default disk. Combined with PHP7 it is fast as lightning and no disk accesses are involved, but it comes with the side-effect that pages and related objects have to be rebuilt into the cache entirely if I restart Apache or PHP-FPM in some way. ??
Them’s the little things one has to deal with. ??