When people ask whether Sam Ruby is advocating an alternative to web services, reply that he is not. Reply instead that he is advocating some additional constraints. Permit me to explain.
There are those who appear to advocate a null architectural style with respect to data. Who claim that content type independence is not a bug but a feature. Who imply that few constraints on data is a good thing. Of course, there are no such people, this is only a strawman argument.
Now consider RSS.
What is important to the success of RSS? I suggest that it not the methods by which RSS is created, updated, and deleted. Instead, what is important is the uniform representation of shared concepts. Concepts such as channels, items, titles, links, and descriptions.
Local optimizations may occasionally benefit by bending architectural constraints a little. Blosxom, for example, supports the ability to "Create, edit, rename, and delete entries on the command-line, via FTP, WebDAV, or anything else you might use to manipulate your files. There's no import or export; entries are nothing more complex than title on the first line, body being everything thereafter."
Such tight coupling may make sense within a component in a complex system. However it is important to identify the points where one may cross vendor, language, platform, or trust boundaries as these represent critical architectural junctions. Ideally at such points one applies the intersection of the architectural constraints of Web Services and Representational State Transfer. In the case of RSS, a reasonable approximation of this is achieved by retrieving well formed and valid XML documents via HTTP GET.
Is this ideal? No evolving protocol is ever perfectly in sync with the challenges it faces. RSS could benefit from an explicit schema. RSS could benefit by more explicit rules defining whether HTML is allowed in titles or relative links are allowed in descriptions. RSS could benefit from a more clear separation of metadata from data. RSS could benefit from an ability to explicitly mark what items must be understood, and which are optional.
In fact, RSS aggregtors may quite possibly be pushing the limits of the Internet by implementing a polling architecture on top of HTTP GET. Architecturally, this seems pretty dumb.
But it works.
For those interested in futher reading on this topic, REST + SOAP attempts to capture the best features of each "alternative" and shows how they can be constructively applied together.