You realize he is a core kernel dev, right? He's splitting into pieces one at a time. When a part of Linux sucks and your patch changes it, upstream has you change the part that sucks and then adapt your patch to it. Makes things often take longer than necessary for new contributors.
To give you an idea of Kees's contributions:
~/git/linux (master)$ git remote -v
origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch)
origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push)
~/git/linux (master)$ git pull
Already up-to-date.
~/git/linux (master)$ git log --author="Kees Cook" --pretty=oneline | wc -l
701
Basically, he is getting as much of grsec as is feasibly upstreamable upstream as he's able to. Due to upstream Linux policies, the end results often turns out very different than the original grsec patches they were extracted from. Perhaps that is a better way of putting things?
Other people have gotten large changes into the kernel before, but they require interfacing with the kernel devs and agreeing to certain changes first. Nobody's going to accept a patch just because Google wants it for one of its products. And Google isn't going to change its product patches just so they can fit in mainline.