This ignores the history of many of these. The webkit-prefixed names came first, and the standardization folks just decided to make the unprefixed forms work the same way. If Chrome implements something as a prefixed property that folks start to use, standardization will be heavily skewed towards their syntax and semantics.
Also, the document does not include some things like -webkit-gradient which Firefox still implements (though I'd like to try and remove it). -webkit-gradient has more features than standardized foo-gradient and causes some complexities in the Firefox code.
(-webkit-gradient wasn't a Chrome thing, however, it was an Apple thing. There's a long and boring history here)
> but not for the -moz or -ms prefixes?
There aren't (m)any webpages out there using moz/ms-prefixed properties that don't use the webkit or standardized versions too. Also, IIRC Firefox and IE stopped prefixing things earlier on (could be wrong here).
I assume because the feeling is that -moz prefixes no longer form part of the "de facto web." Targeting for desktop Chrome isn't as common anymore, but this document seems squarely aimed at the mobile space, where Safari-specific (and to a lesser extent Chrome- and Android-specific) functionality is more or less epidemic.
My impression is that there aren't any closed-source bits in the browser itself (i.e., there are no proprietary patches to Chromium code), it's just the Google account integration, plus things like Hangouts or Cast or whatever which mostly take the form of extensions, plus things like the Flash plugin.
(Also, that compat page looks very non-monstrous; the vast majority are just aliases for non-webkit-prefixed names, and of the remainder, nothing is anywhere comparable to CSS filters or XHR. Is there a reason this exists for the -webkit prefix but not for the -moz or -ms prefixes?)