Perhaps there's a middle-ground solution - a universal prefix that denotes experimental or non-standard features that may be liable to break or not work cross-browser.
In the long-term (i.e. a major browser release), once the property is stable and has been standardised (or is a de-facto standard) then the prefix can be dropped.
This experimental prefix could exist side-by-side with vendor prefixes to allow for workarounds for broken draft implementations.
The problem is that unless two properties are actually going to work the same way, we can't use the same prefix. We have to be able to target individual, misbehaving browsers.
Its not just IE that's quirky - Firefox, Chrome, and Safari all have CSS bugs that have to be accounted for. Its hard enough to target them individually now, but under your proposal it would be nearly impossible.
But of course, this is not what the author is discussing at all. He doesn't have a problem with vendor specific prefixes in general, but rather feels they should be deprecated more aggressively once widespread adoption occurs.
That's rather common with MIME types, HTTP and MIME headers, where experimental or vendor-specific extensions get prefixed with "X-". The same thing could work here, I agree. I think that "-x-transition" would work better than "-webkit-transition", frankly.
In the long-term (i.e. a major browser release), once the property is stable and has been standardised (or is a de-facto standard) then the prefix can be dropped.
This experimental prefix could exist side-by-side with vendor prefixes to allow for workarounds for broken draft implementations.