It really depends on why it's being cached and how the application (feed reader, aggregator, and/or directory) is designed.
They're "supposed" to cache the feed to reduce bandwidth and server resources on the feed's originating site. The cache "should" be deleted and replaced with a current copy of the rss feed whenever the feed is modified. Meaning if an article is deleted, then the feed reading application should replace the feed's cache with the new version that doesn't have the article.
One application I know of, replaces the cache every time the feed reports it's been modified and replaces the cache every 8 hours if the feed hasn't reported it's been modified. The application has to do this because most feed's aren't reporting when they've been modified.
I say "supposed" and "should" because I don't know how every application has been designed; I just know what feed caching is "supposed" to be for.
IMO, the biggest thing a feed creator can do, is ensure that his/her server is using the if-modified-since. This way, feed readers know when the feed has been modified and can ensure their cache contains the updated feed, and not an outdated version that contains information they don't want included. The biggest thing a feed reading application's developer can do is incorporate the if-modified-since headers and refresh the feeds cache less than daily (but not too often) in case the feed doesn't report it's been modified.