The concept you list are orthogonal to most sources of kernel vulnerabilities and most of grsecurity's defenses: C-related exploitable memory safety bugs.
grsecurity's C exploitation mitigation tech is just a band-aid for these.
Of course a kind of Amdahl's law applies to these: eliminate memory safety related vulnerabilities, capabilities and such become important
in eliminating the rest of the bug classes...
Yeah, but you get really far by eliminating memory and control flow attacks. There's also relatively cheap ways to do that with hardware and software. There's even schemes like SAFEcode/SVA, Code Pointer Integrity, and Softbound + CETS that do it automatically with a performance hit many apps can take.
Yet, what's uptake of such methods in mainstream, kernel development? There's the problem.
Or you could just use a memory safe language instead of getting into the C mitigation arms race.
Time and time again mitigation techs have gotten widely deployed, exploits have caught up, it's a perpetual cycle. Yes the exploitation gets a little harder each time around, but you don't get sound memory safety that way.
I agree: my main recommendation for new projects. However, avoiding C or porting Linux/BSD to a safe language fell on deaf ears for decades. So, for them, I recommend techniques that work with C and UNIX architecture. Maybe more progress that way.
Of course a kind of Amdahl's law applies to these: eliminate memory safety related vulnerabilities, capabilities and such become important in eliminating the rest of the bug classes...