I think it more a question of backward compatibility.  Anyone who was using the previous RSS (Newsfeeds) module, had the choice already to use  non-RSS v2.0 feeds and custom XSLs.  Of course, you could opt to use the XML/XSL module instead, but for those that didn't, there is a considerable amount of work to do to convert the existing RSS modules to XML/XSL, in light of the fact that the new module 'forces' the use of the 3 existing stylesheets which are only RSSv2.0 compliant due to the new module converting all feeds to RSSv2.0, and really just a subset of RSSv2.0, not all elements are supported. 

The idea of having the RSS module allow 'single feed' or 'aggregated' feed options is to allow folks to bring up the new module without worrying about having to do a lot of pre-install work to convert their existing modules over to the XML/XSL module.  Then, when they understand the new module's capabilities and nuances, they can aggregate or move their 'single feeds' over to the XML/XSL module without having to rush into anything.

The bulk of users would already be using 'single feeds' as that's what the old module supported, and yes it is similar effectively to the XML/XSL module, but it's been that way since the early days.  The biggest negative that folks tell me about moving to the new module is losing the existing setup of modules that are working in the old module.  It really doesn't matter why, though I suspect most were because of the strict validation requirements.  Since, the new module did not have a 'readme' doc, or 'breaking changes' doc with it, many people were caught off-guard by the new module's processing and feed requirements.

I'm not saying that the choices were wrong, just that it might have gone a bit better.  I'm recommending that folks ONLY use the new module for circumstances that require feed aggregation.  At this point, there is no need to use it for single feeds presentation, due to the lack of support of the full rss v2.0 elements.  Even, other feed types such as OPML, RDF, and ATOM feeds suffer a bit of loss due to the incomplete translation of those formats to DNN's RSSv2.0 format.  Although, some users with little experience may find even single feeds are easier to setup with the new module, as long as there are no errors during the internal conversion processing. 

Also, though I always instruct folks to test any new module in a non-Production environnment, it seems to be the case that most folks never do.

The work being done in this new module is going in the right direction overall, and I'm continuing to pursue fixes for the pieces I can manage.  I just wanted to bring the topic up, as it's been a question I've been asked a lot. 

The whole issue with strict validation is not even the wrong decision in my mind.  Other opportunities for adding features are simplified with standardized element content, and are just about impossible to provide without them.  For example, sorting becomes a very tedidous chore without having a known date format.  I've added the feature making mods to the module settings code, but it relies on some very structured input date formats, otherwise it breaks.  Just a coding issue to get around, but one that would not be a problem if strict format is used. 

The main point is that folks would not have seen the problems in the beginnning if backward compatibility was provided.  Now, as I say, it may be a moot point, but just throwing it out there for future reference.