If you read about FriendFeed's Simple Update Protocol (http://blog.friendfeed.com/2008/08/simple-update-protocol-fe...), you'll find some good arguments about why RSS slow. The crux of the problem is that to get any updates on a feed, you have to request and download the entire RSS feed (which is filled with summary text and is of nontrivial size).
Consider the case of a real-time news aggregator. A news source doesn't update very frequently (say once every 5 minutes), but you want to provide updates super fast (say within 30 seconds). That means on average you have to scrape the entire RSS feed 10 times for a single update. On the other hand, FB/Twitter APIs give you the flexibility to do things like "download items after this id," which hog much less bandwidth.
Looking at that article, the slowness doesn't come from having to download the entire RSS feed. As commenters there note, If-Modified-Since means you only need to download the feed when there are changes. So in your second paragraph, you have to ping the RSS feed 10 times, but you'd only need to download it once.
Rather, the slowness seems to come from the lack of an aggregation mechanism. If I want to follow 100 feeds (e.g. 100 Twitter users), I have to query each of those 100 feeds. Even though I can query them efficiently using If-Modified-Since, that's still slower than firing off one query to find out which of those 100 feeds have updates, and then querying only those which do.
Consider the case of a real-time news aggregator. A news source doesn't update very frequently (say once every 5 minutes), but you want to provide updates super fast (say within 30 seconds). That means on average you have to scrape the entire RSS feed 10 times for a single update. On the other hand, FB/Twitter APIs give you the flexibility to do things like "download items after this id," which hog much less bandwidth.