On the one side, mainline has an old long-term plan of removing GCC plugins, to be replaced either by native compiler features, or LLVM/Clang plugins. Both solutions effectively leave many Linux users unprotected, because pretty few Linux distros build the kernel with Clang, or because it will take years until the compiler features which aren't implemented yet reach multiple important distros, let alone the Enterprise (TM) ones. ISTR that Google builds Android with Clang, so LLVM/Clang plugins could help protect that large contingent of users of _future_ versions, but not billions of users of past versions (without backports, that is, but aren't most older versions unlikely to receive them ?).

On the other side, PaX/grsecurity doubles down on GCC plugins, because, despite the relative maintenance headache that they arguably cause (PaXTeam, spender, minipli, Emese Revfy, and/or whoever else has maintained them and maintains them nowadays seem to manage to cope with it), they have always represented a pragmatic solution for protecting users yesterday, today and tomorrow, against both old and new threats. I remember reading that GCC plugins ease maintenance of PaX/grsecurity, by replacing manual changes, and thereby free up more time for designing new defenses, too.
The 2017-2021 grsecurity patches published under the GPLv2 show that:
* AUTOSLAB (per-call-site slab partitioning, which, in my understanding, would be superior to type-based slab partitioning mentioned in this article);
* CONSTIFY (opt-out constification of statically allocated objects, e.g. ops structs);
* LATENT_ENTROPY;
* RAP (three-way forward edge deterministic + backward edge deterministic + backward edge probabilistic CFI, which makes it far superior to hardware implementations such as Intel CET - the grsecurity blog details how);
* RESPECTRE (automated patching for against speculative access issues, instead of manual patching for a handful of sites);
* SIZE_OVERFLOW (integer overflow prevention)
and several others have been implemented for years as GCC plugins, with extensive backwards compatibility to older GCC versions. Not to mention that they pioneered RANDSTRUCT that way, too, well over a decade ago.

Another topic: aren't layout randomizations, be them for address space (KASLR, FG-KASLR, etc.) or structs (mentioned in this article), and the associated complexity and boot-time slowdown, high cost and relatively low payout, when there's lower-hanging fruit, such as a mainline Linux kernel missing MODHARDEN-type functionality ?
There are already occurrences of "MODHARDEN", which locks down unprivileged module auto-loading, in grsec patches from 2011. I saw several weeks ago that in the 2021 grsecurity patches, the hunks containing MODHARDEN represent ~100 (not a typo) raw lines of patch.
Unprivileged module auto-loading for uncommon network protocols or filesystems, whose implementations are full of vulnerabilities, has been spotlit in the recent string of LPE exploits: Copy Fail, the Dirty Frag family, etc. Denying unprivileged users the ability to trigger auto-loading of a vulnerable module breaks exploits which depend on that non-default-loaded module being auto-loaded. Then, PaX/grsecurity typically further break the recent exploits by taking extra measures to disable io_uring and by at least shunning unprivileged user namespaces, both of which have consistently shown themselves on the vulnerability feeds over the years, and were also used in the implementation of some of the recent exploits, but that's another matter.
By now, since over 15 years ago, MODHARDEN alone has made it impossible for unprivileged users to exploit dozens, if not hundreds of vulnerabilities in the Linux kernel.