He does go on to mention that 'HTML5 will save us' - at least from quibbling over <br> vs <br />...
http://html5doctor.com/absent-elements-and-validation/
http://wiki.whatwg.org/wiki/FAQ#Should_I_close_empty_element...
It's not like any browser is going to drop the html4 doctype so until there is widespread support for html5 elements (footer, article etc) there is no real benefit other than pr.
Whereas having a doctype that matches the tags you actually use, (xhtml or html4) will work fine without the http:// prefix. As most people don't use that prefix when typing your url, this can have a drastic effect on your page views.
I've not heard about it before and Google's not giving me anything.
It should be trivial to setup a test case if you want. Setup a virtual host with an empty content-type html header, and a html5 doctype and open it in IE6 without putting http:// before the url. You should see it try to download the page.
Browsers sniff the doctype to change rendering mode, but that's after they've already decided that it's HTML that they're going to display.
IE6 & 7 do content type sniffing, where they ignore what the server tells them it is and try and figure it out themselves, by looking at various bits of info including the start of the file.
This could lead to HTML being downloaded if it happened to look like a RAR file to IE, but generally it has the opposite effect as in something being sent as plain text that happens to include tags being rendered as HTML.
If anything, shortening the doctype should make something look more like HTML since it works without any doctype at all and the shorter the doctype the more room for HTML tags.
On the other hand content-sniffing is always going to give you unexpected results. Is there anything about the particular file you had that makes it atypical or likely to look like a binary file if you only consider the start of it?