Why doesn't FreeBSD merge security features from HardenedBSD?

You clearly haven't used any BSD ever before.
Why not go and get a clue?
You might actually like it.

Kill yourself.

Stop derailing useful threads with license shit. You don't see me going into every Linux thread to talk shit about RMS.

Yeah I think he's clearly trolling.
Or dumb as a brick, could be both.

OP here, so far there haven't been any conclusive reasons mentioned for FreeBSD to completely skip Exploitation Mitigation.

IIRC, there was a FreeBSD patch circulating that added some form of ASLR, but I don't know what happened to it.
(This particular patch was not authored by lattera, his work formed HardenedBSD)

ASLR was described as a "small hurdle", but isn't it true that every hurdle counts for something.
Consensus amongst security professionals seems to be generally in favor of exploit mitigations.

What transpired is that perhaps FreeBSD doesn't see itself as a security-focused OS, rather embracing their status as a simple worker that is good at one particular job (e.g. Netflix) where security is handled elsewhere.
Could that be the sole reason?

To be fair you can remove the compat modules if you don't need them. Using your own kernel build is extremely easy and boils down to 2 make commands once you have your config file made and sources synced.
freebsd.org/doc/handbook/kernelconfig-building.html

Specifically to remove compat you'd just copy the GENERIC conf file to whatever name you want, comment out the compat_freebsdX kernel options, then build and install it.

I don't even know anything popular that relies on them outside of some proprietary drivers, which is why they bundle it with the GENERIC branch.

This modular approach to compat is one of the biggest draws to the OS for me, there if you need it, not if you don't.

Maybe they should rename themselves to Opensolaris and FreeBSD devs would implement their patches.

I want to reiterate some things I mentioned here but a little more loosely

Security isn't always free and the cost isn't always worth it to some people. The argument could be made, "where is the sense in running X% slower 100% of the time when you trust your environment already", not to mention some of these patches are not bulletproof, they're hurdles not walls.

2 related topics to think about that people typically argue about more, look at how people fight over languages like C vs something "safe" and managed, a big knock is always the performance.

Which is more important to you, performance or security, is obviously subjective and usually case dependent, for instance you probably don't have to worry about security on some isolated machine you use at home, but it's different in other scenarios.

Intel's latest fiasco is a good thing to bring up here, with people speculating a 30% speed decrease in certain operations. I've seen some home users saying their going to use outdated Linux kernels because they don't think the impact is worth it for their use case.

I also want to point this out
it's not like you can't use these things in your own build if you want/need them, obviously they're out there, but does every FreeBSD user need them by default? Probably not, so incurring some kind of penalty on them may not be desirable. Imagine the percentage of security focused users vs those that are not under constant threat and the cost associated.

I don't doubt it but it's probably not the sole reason. The fact that a fork exists and other security oriented projects also exist, may be related. Different goals and the ease of integration if you do desire these things alleviates any pressure, they can easily just point and say "use patchset X or project Y if you want feature Z".

I think another thing worth mentioning is security people argue over what is and isn't a solution, I know the OpenBSD people don't like the idea of jails so much where FreeBSD people think it's fine. User requirements and their level of comfort with mitigation strategies vary widely.

For me personally I'd be okay with someone exploiting one of my jails because it's isolated, if they manage to get into that isolated system, I don't care, I don't need ASLR for this sandbox, they can have root in it for all I care, I'm nuking it anyway, its only purpose is to run this service and it can't do anything else.

OpenBSD people take a different approach making sure these kinds of things don't happen in the first place. Which in my opinion is noble and the right answer but not practical. No matter what the claims are I'd rather never trust a system and just isolate it than expect it to be bulletproof because some people audited something and found no obvious problems at the time.

To put that simply, it's all a bunch different paradigms, no 1 things is the answer, including just mixing all the standard practices together.

Therefore no one would. I also hate their dump file policy. I wonder what did they do against row hammer though it should be fixed by intel.

Probably just don't worth the effort. While OpenBSD can freely experiment, FreeBSD is still used in data centers and they must think about 3rd party support too.