I think the best thing you could do is maintain a source package for the distribution based on their vanilla kernel package and create a list of PaX exceptions. Making a binary package available is worthwhile, but third party binary packages are a bit sketchy unless you've built a good reputation in the community.
By the way, Arch Linux has an official grsecurity package in addition to that LTS one in the AUR:
https://www.archlinux.org/packages/comm ... nux-grsec/https://wiki.archlinux.org/index.php/GrsecurityThe downside to a binary package is missing out on the RANDSTRUCT and HIDESYM features. However, binary packages mean more users, and those users will improve the experience for everyone by finding bugs like SIZE_OVERFLOW false positives. Many people aren't interested in compiling a custom kernel, especially on old / embedded / mobile hardware.
Arch makes it easy to build a custom version of an official package so it's strictly better than not having one. The binary package makes it very easy to try out grsecurity and then the underlying source package makes it trivial to build a custom kernel that's properly integrated into the distribution. The same thing will apply to the NixOS grsecurity implementation, but I don't think they're at the point where there's a binary package.
It would be awesome if there were official packages for more distributions, but there's a lot of politics involved. It only ended up in the Arch repositories because I'm stubborn and went ahead with adding it despite it being a very contentious issue.