>>844732
I want to reiterate some things I mentioned here >>843609 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 >>846575
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.
>What transpired is that perhaps FreeBSD doesn't see itself as a security-focused OS...
>Could that be the sole reason?
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.