You hit Feed Y every 30 seconds which is silly because it's probably updated once an hour or less. Every time you hit Feed Y, you get the RSS for the last 25 postings which takes up bandwidth and possibly processing power for the remote server to generate and processing power and bandwidth on your end to download and consume. BAD! So much waste trying to make sure we get instant updates!
So, Feed Y creates a little "I was last updated at time()" feed. You download that and are transmitting very little unless there's an update in which case you grab the feed. Awesome! Now, I ping 1,000,000 "I was updated at time()" feeds for various Facebook users. . .hmm, that's a ton of HTTP requests and transmission over head.
Scratch that, let's have Facebook create a single feed of all their feeds that have been updated in the past 60, 300, and 600 seconds! So, we hit that every 30 seconds and update then grab whatever is new! Wow! That means that for me to digest updates for all my users who want their Facebook feeding into my service, I just hit one SUP feed and then grab whatever that SUP feed says has changed. That's a lot better than hitting 1,000,000 feeds every 30 seconds.
So, this isn't good for your RSS reader or whatnot, but it would be huge for sites like Friendfeed or anything that feeds Friendfeed since it would reduce the bandwidth and processing on both sides. As they said, they are likely to miss some updates with SUP, but if they can get 90% of the updates that way, they can change from pinging individual feeds every 30 minutes to pining them every 300 minutes and still get new items 10 times as fast by pinging the SUP feeds every 3 minutes.
Cool. Practical. Open. Good-Neighbor vibrations for services they pull from. Could even be game changing as it could allow you to aggregate the data you like over many services in a way that was too bandwidth/processing intensive to scale if everyone started doing it.