I agree with you fully that mixing up kernel hardening and userspace hardening is one thing, but to suggest this little repo: https://github.com/Kicksecure/security-misc offers the same level of kernel hardening as grsecurity is probably the funniest thing I've read today.

To start with, some of the protections in grsecurity (specifically PaX) offer protections that apply to userspace - specifically MPROTECT and PAGEEXEC. Then there's the many kernel level protections: KERNEXEC The 3 different ASLR options (yes, vanilla linux has some watered down versions of these)

Then there's all the options that your little github repo has nothing the eqivilent of (to be fair vanilla linux HAS backported some of these):

  [ ] Sanitize all freed memory  
  [ ] Sanitize kernel stack  
  [ ] Prevent invalid userland pointer dereference  
  [ ] Prevent various kernel object reference counter overflows  
  [ ] Harden memory copies between kernel and userland  
  [ ] Automatically constify eligible static objects  
    [ ] Report code regions instrumented for writing to constified data  
  [ ] Automatically constify eligible allocated objects  
  [ ] Prevent various integer overflows in function size parameters  
    [ ] Increase coverage of size overflow checking  
    [ ] Log missing size overflow hash table entries  
  [ ] Free more kernel memory after init  
  [ ] Free more kernel memory after init (verbose mode)  
  [ ] Generate some entropy during boot and runtime  
  [ ] Prevent code reuse attacks  
    [ ] Forward edge defense (deterministic)  
        └─ Forward edge defense instrumentation method (callabort)  
    [ ] Backward edge defense (deterministic)  
    [ ] Backward edge defense (probabilistic)  
  [ ] Protect kernel stacks from each other  
    [ ] Report nolocal transformations  
  [ ] Automatically protect kernel code vulnerable to Spectre v1  
    [ ] Protect more kernel code vulnerable to Spectre v1  
    [ ] Automatically protect kernel code vulnerable to Spectre v4  
      [ ] Protect more kernel code vulnerable to Spectre v4  
    [ ] Report code found to be potentially vulnerable to Spectre v1/v4  
  [ ] Convert k\*alloc allocations into their own slabs  
    [ ] Report autoslab decisions  
  [ ] Report some potential NULL pointer dereferences
  
  [ ] Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port  
  [ ] Disable privileged I/O  
  [ ] Randomize addresses of critical kernel objects  
  [ ] Harden BPF interpreter  
  [ ] Disable unprivileged PERF_EVENTS usage by default  
  [ ] Insert random gaps between thread stacks  
  [ ] Harden ASLR against information leaks and entropy reduction  
  [ ] Deter exploit bruteforcing  
  [ ] Hide kernel symbols  
  [ ] Randomize layout of sensitive kernel structures  
    [ ] Use cacheline-aware structure randomization  
  [ ] Active kernel exploit response
  
  [ ] Dmesg(8) restriction  
  [ ] Deter ptrace-based process snooping  
  [ ] Require read access to ptrace sensitive binaries  
  [ ] Enforce consistent multithreaded privileges  
  [ ] Disallow access to overly-permissive IPC objects  
  [ ] Disallow unprivileged use of command injection  
  [ ] Disable ability of suid root apps to execute unsafe files  
  [ ] Auto-enable Spectre mitigations for suid-like applications  
  [ ] Trusted Path Execution (TPE)

I've only grabbed half the options that grsecurity has available as options to turn on, but you get the idea. Later version of the grsecurity patch also offer kernseal - https://grsecurity.net/featureset/memory_corruption

So yea - to suggest your little github repo that tweaks a few kernel settings is anywhere near the massive security hardening feature set that grsecurity delivers is also, well, embarassing.