Since we're talking about CloudFlare at all, we are automatically in a security context.

In a security context, automatically poking a hole through for RSS is automatically giving attackers an easy-to-use door straight through to the underlying site to DDoS them.

You might want to say "Oh, well, then, let's just set some bandwidth rules", which will certainly work for specific sites, but it's going to be difficult for CloudFlare to correctly guess them generically. (Not necessarily impossible, but it is impossible if you measure it from the POV of them never being wrong. It would only be a heuristic guess.)

Attackers do not read responses from HTTP requests either. I think it's fair that the default behavior is to protect all endpoints and a user can explicitly change the behavior.

They'd have to probe every endpoint to figure out the content-type of the return.

And if your web application allows queries that produce RSS feeds that could still result in a really bad L7 attack if you simply were to ignore all feeds. No caching + randomized queries on a small site would knock it offline in no time.

I would think that a good caching solution on the server for RSS requests could perform decently even under DDoS scenarios... though, this is why people used other services in front of their RSS feeds, so that they were better cached. Most blogs aren't generation more than a couple new articles a day, so caching 15-120 minutes wouldn't be an issue for most use cases.