SELinux is an absolute must in todays world, simply put it prevents applications and namespace from doing thing outide of their area of interet, for example a web server should never be allowed to execute files from /tmp so it prevents that, another great example is when you have any form of multi-tennancy - for example you might have several docker or LXC containerised apps running on a host SELinux will / can ensure that even if of those apps is compromised and someone popped a shell in it, they couldn't go beyond anything running in that namespace, i.e. to the host itself or other apps running in containers on the same host.

It prevents a lot of sitations where an app might behave badly, for example perhps you're running a PHP app and a 0-day PHP flaw is discovered, there's a good chance that SELinux restrictions could prevent that exploit from being useful to the attacker by not allowing the app to do unusual things.

We have a rule - if it's not running SELinux in enforicng then it's not going into production.

We use to run GRSec as well, however with modern kernels a lot of the GRSec code base has been merged in so it's often not required.

I agree with you except for the GRSec part - most GRSec features are still missing except for a few low hanging fruit.

grsecurity is enhancing the security of the kernel itself, SELinux is for user space applications.

That's an oversimplification. Grsec protects both kernel and applications, although mostly via separate systems. Selinux mostly protects applications, but can also stop malicious interactions with kernel code (syscall and virtual file access restrictions)