* Many, many client developers will be confused by this approach. Also if they're using a shitty http library (often, yes) they'll hate you.
* What happens when someone sends an "Accept: application/json"? If you default to "send the latest" developers will fail to read your docs and get pissed when your next version breaks their code.
* His citation of Fielding's dissertation at best fails to support his claim and at worst is a misunderstanding of it. How is "put this in your accept header" any more of a uniform interface than "this thing goes in urls"? If you're doing HATEOAS properly the answer is: "accept headers are less general and thus worse". If you include api versions as a fundamental part of the notion of a resource they seem to become important enough to need top level (e.g. URI) support.
All in all this seems like a thinly veiled argument for URI purity for its own sake. API versions change the definitions of what a resource looks like and what you can do with it. What more is there to a resource? What benefits, aside from sweeping the versioning mess under the header rug, does this provide?
I don't think REST meaningfully comes down on either side of this idea. I do think practicality sits highly in favor of versions in URIs.
But that aside, what happens when you store versioned resource URLs in the client, and then you want to upgrade your client to a new version of the API? Do you just lose all of your data from the old version, since you don't have a single URL for a resource?