The object cache is not reliable, in any case.
For example, Memcached has its own system to purge items in cache: if it “thinks” that is too full it start purging items in way that is just not predictable.
It is (or should be) known that when you have an external object cache system in place, calling wp_cache_set provides zero warranty that the cache is set. And surely wp_cache_get provides zero warranty the cache is get.
This is why core does not care about what wp_cache_get / wp_cache_set do, and to be honest, there’s no way they can do that: WP allows complete override of cache functions, so core has completely no clue what those functions actually do, because those functions are literally re-written by 3rd party.
On the other hand, popular cache systems are designed to be very fault tolerant, and large-scale WP setups use redudant cache servers: when, let’s say, four cache servers are connected to an application, the odds that update fails in all them are scarce. On top of that, such large-scale WP setups have monitoring in place to check health status of cache servers.
That said, the possibility of issues is never zero. This is why, for example, no hosting provider says “uptime 100% guaranteed”.
Even if you remove the cache variable, a glitch might happen also in DB connection, and again, only redundance and monitoring can mitigate that.
In conclusion, yes, cache can be problematic, but no, WP core can’t really do anything about that. Redundance and monitoring helps in lowering the possibility of issues to an acceptable level that, in any case, is never zero.