This looks like a list of bugs that need fixing; ideally, headless Chrome should be completely indistinguishable from ordinary Chrome, so that it gets an identical view of the web.
It depends on the target audience. For Google (and for most people) the goal of Headless Chrome is to offer an easy and feature-complete way of automatically testing websites, e.g. for performance (PWA are all the craze) and bugs. For those folks, it doesn't matter that you can detect the Headless Browser, it only matters that it's working like the regular one 99% of the time. This is a huge step-up from previous technologies like PhantomJS or laborious solutions involving webdriver and many moving components.
In some cases they don't even want it to behave exactly like the regular browser. As soon as your website uses any client-side state (cookies, IndexedDB, HTTP caching, service workers, local storage) you want to have to an easy "give me a clean and isolated browsing session" switch like Headless offers.
People scraping the web are not the target audience of this.
But to automate testing, you probably need working locale support, and APIs for images to function. Those items will probably stop working for detection purposes when they fix them.
I wouldn't be that surprised if they added webgl support later as well.
I tend to disagree with your stance on Google's incentives. I'm pretty confident (and have zero factual ground for this) it is exactly taking over the bots industry with a powerful headless browser, that pushed them to release headless chrome.
Mind you Google is extremely interested in bots...
And, indeed, even if it wasn't, you could always do your malicious scraping et al using regular Chrome with a remote-control extension or OS Accessibility API-based automation. It's kind of pointless to detect headless browsers specifically, if you'll still have the same problems from automated headed browsers.
Still, I agree that if people are going to try detecting headless Chrome, Chrome should strive to thwart that. The attacks in the OP seem like low-hanging fruit; I was expecting something more akin to timing attacks on how long Ready events take to fire given delays from actual rendering. Writing the code to imitate that would be a fun week.
