DRM for the most part is encryption and if you want to have it with all the vector voodoo of video compression it has to be built in.
That said today there is no way in hell to make a codec without DRM and expect it to have wide support, lack of DRM is actually killing more projects (like various open source streamers) than outrage of the free software community will ever be able too.
An open codec is only viable if it's worth to be picked by the big players and those are the big media and content providers who won't pick up a penny if it didn't had DRM support...
CSS, AACS and HDCP are all broken, Flash is on its last legs and music downloads have largely abandoned it to positive consequences. Streams seem to be the last bastion, but that doesn't even make sense -- the reason people subscribe to Netflix is to watch new content every month, not to watch the same content over and over. If they wanted to do that they would just buy the Blu-ray (or, if so inclined, pirate it once). And pirates have no reason to rip a 6Mbps stream when they can rip a 40Mbps Blu-ray.
DRM is a box you have to check when a suit was bamboozled by a DRM snake oil salesman into putting it in a contract. How the DRM works is irrelevant because it won't actually work anyway. A fig leaf doesn't need codec support.
That's what EME is about, and that's why you hear the free software people griping about it but not the actual pirates. EME makes piracy easier. It separates the DRM into its own little box which makes it easier to circumvent. Which is what the pirates will do because they don't care about breaking the law, but which law-abiding free software people are proscribed from doing by DMCA 1201.
But the most fundamental flaw in your argument is that you misunderstand who decides what DRM gets used. DRM is not content. What gets supported is ultimately decided by the platform companies. When Apple says there will be no DRM on iTunes, there will be no DRM on iTunes. The only thing Disney or Universal can do about it is withhold their content, but that costs them more than it costs Apple or Google. Which means it isn't something they can credibly threaten unless the dispute is of a make or break significance, and the particulars of DRM implementation are not on that level.
Everybody 'hates' DRM, it seems but I don't think it's going anywhere and I don't think you can ship a codec standard without it. You usually want hardware support for the DRM encryption. I don't know the specifics of their technology, but Netflix and Hulu and Amazon all stream tons and tons of media and I'd be surprised if it wasn't DRM'd in some capacity, I know the video apple sells/streams all is.
http://www.w3.org/2000/12/drm-ws/pp/koenen.pdf
H.264 (trough IPMP), H.265 also implement in-bistream DRM interfaces directly into the decoder...
IPMP does not in any meaningful way alter the H.263 or H.264 compression algorithims, even though it does alter the bitstream in ways that require modifications of the encode/decode pipeline
There is nothing stopping a third-party from similarly making a pipeline-invasive DRM for any open codec. As a matter of fact, if the open codec is patent free, then there would be no legal way to stop them.
And while you can make a DRM free encoder it's still wasn't the argument that i was talking about if there won't be a well established and well integrated DRM mechanism within the design of the Codec it will be dead in the water since for a codec to be widely accepted these days it needs to be adopted by the media/movie/tv/streaming/content delivery whatcha gonna call it industry and that industry needs DRM. Heck even sites like YouTube use DRM these days (paid content trough), Twitch and other similar sites will eventually have to enable DRM too if they want to offer premium content as it's much easier to gate people with DRM than to have some weird session based authorization for streaming which is a nightmare and doesn't really work as DRM. And using multiple codecs (cie? x's? xes?) is probably not a viable approach either.