Legend:

I shall point to the more pointless unserialization with get_option() which has no process to copy its unserialized value to the $wp_object_cache->cache, on first unserialization... Which means that with the basic wp object cache, get_option() has to run maybe_unserialize() and unserialize() for every other calls to the same serialized option, making get_option() quite redundant there.

9

9

10

The "caching by groups" concept (e.g. alloptions) with the current implmentation of get_option() have unavoidable unserialization waste, one a way or another. And even with memory cache, because wp_load_alloptions() loads early, you cannot not store objects in the 'alloptions' groups for any plugins, if the cached options are stored as objects (or arrays of object), due the classes being no yet loaded. Having them serialized allows for just-in-time unserialization for plugins.

10

The "caching by groups" concept (e.g. alloptions) with the current implementation of get_option() have unavoidable unserialization waste, one a way or another. And even with memory cache, because wp_load_alloptions() loads early, you cannot not store objects in the 'alloptions' groups for any plugins, if the cached options are stored as objects (or arrays of object), due the classes being no yet loaded. Having them serialized allows for just-in-time unserialization for plugins.

11

11

12

12

It's not perfect but the current model is to store everything as serialized, not making them Arrays or Object ONLY on update_option() or add_option(), in a very inconsistent way like that.