A polyfill of <picture> much more expensive. First you have to shiv IE to accept it as a DOM node. Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>. Polyfilling "srcset" is trivial as in:
if browser is modern and high-res,
replace the value of src.
else
pass
Doing a flash video polyfill of a video tag is okay because there is probably only one video on the page. Polyfilling <picture> would produce some seriously janky page rendering, and would be a pain in the ass to maintain.
In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning for anyone who isn't strict about pure semantic HTML, they could just stick an img in there for older browsers.
> First you have to shiv IE to accept it as a DOM node
I find this an increasingly weak argument as it's applying to <10% of the market and falling fairly rapidly ahead of the 2014 Windows XP end of life and is true of everything else in the HTML5 spec.
> Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>.
This is a reasonable complaint - I'm not sure I'd consider it a big deal since the work of manipulating the DOM is a lot faster than doing anything like downloading an image or rendering it but for anyone trying to do a wall of images it'd be worth benchmarking at the very least.
