1. The oEmbed spec documents two ways to get from the HTML source of a page to the content it contains. One method is simple, let's call it the link method. I could implement it in an afternoon for the Scripting2 blogging software. I have something very much like it, already working. Each story on this site, including this one, has a link to an OPML document. From there, any kind of rendering is possible. The key thing is I'm getting to all the content of the page, with none of the overhead/template stuff. One link element in the HTML is all it takes to make this work.
3. There's a short list of service providers included in the doc. Pragmatically, if you want to be part of the oEmbed club, you have to get them to list your service in the implementations section of the spec. Otherwise how would people find out about your service?
4. The simple way of doing it has ample prior art and works well. We use it in RSS for connecting feeds to HTML pages. And for RSD, which tells editing software who to call to edit the source of the page (which seems fairly related to oEmbed).
5. I think the security argument is bogus. The oEmbed spec has a section that explains how to keep a bad actor from doing a XSS exploit or accessing cookies they have no right to access.
6. The security argument is no different from the argument against embeds in general. We embed tweets from Twitter or videos from YouTube without questioning what they might inject into our reader's browsers. Why does WordPress trust them more than they trust me? I think this problem has to be addressed in some other way.
7. I would deal with the security issue differently. Strip all markup. And use a structural format like OPML so the way the page is arranged can be transmitted without taking any risks that something nefarious is coming along for the ride.
9. I also include a link to the OPML in my RSS feed. Screen shot. I want you to find it, so I leave little hints around everywhere I can think of.