The trouble is that the properties that make a DRM system actually useful(ie. some degree of robustness, enough information about their environment to 'rights manage' in some granular way, and so on) require fairly extraordinary powers over the client system.
The 'Encrypted Media Extension' itself doesn't; because it defines almost nothing(one 'baseline' encryption mechanism that is little more than a toy obfuscation system, along with standardization of some interfaces for asking the non-joke DRM module questions); but it is designed to plug into DRM systems that do, which is the only reason that it has any support at all.
Consider, for example, the BBC's little request list:
Unless it is 'sufficiently secure that there would be the possibility of legal action in the event of bypassing it.', no go.
Unless it 'securely identifies a type of device', no go(browser UA is explicitly noted as not being good enough)
Unless it allows 'identification of the context in which the content appears', no go.
And 'The ability to pass further restrictions to the graphics rendering path if available'.
A set of requirements like that is both a fairly stock summary of what a DRM system should be capable of to be worthy of the name and a set of demands that certainly aren't going to be met in any non-tivoized OSS implementation, and wouldn't even be particularly easy to meet on something that isn't a closed box.
Essentially, once the pointless little baseline case is immediately ignored by anybody who would ever actually use the system(since, if you don't want DRM, you won't want the hassle, and if you do, the baseline is far to pitiful to be worth anything), EME is a 'standard' for 'how to use javascript to talk to an entire black-box video rendering mechanism, upon which there will be enough demands that it will almost certainly be platform specific'. Pretty much exactly the same situation as having the video player stuck in a blob of Silverlight or Flash, except that (because this is HTML5, man) the wicked 'browser plugin' has been renamed a 'content decryption module'(which, as the spec notes, 'CDM implementations may return decrypted frames or render them directly, and 'CDM may use or defer to platform capabilities'). In all but name, it's the definition of a few javascript APIs for interacting with a black-box video path more or less identical(if not worse, given the more robust support for invoking the hardware-protected 'platform capabilities' now present on a lot of consumer gear, which something like Flash was always too dubiously competent to do in any serious way) to the plugin-based video player arrangements of the past.