Linux has had real-time threads (round-robin and, more recently, deadline scheduling) and kernel preemption for a _long_ time. But the kernel isn't fully preemptible all the time, and latencies are not strictly bounded in all such situations (e.g. if you are trying to grab a contested spinlock). PREEMPT_RT is the final icing on the cake, and as far as I know, it makes Linux the first general-purpose OS that has full realtime guarantees.
But I haven't been able to figure out anything that would indicate FreeBSD is better (or is better than what Linux was in 2016). The information is sparse, but it seems to me that it has a scheduler with _some_ support for realtime threads (when the timeslice is up, RT threads take priority in the scheduling algorithm), but not really preemption of non-RT threads by RT threads (ie., when a RT thread is ready to wake up, non-RT threads get kicked out even if the timeslice isn't up), and I cannot find anything at all about the kernel being preemptable by userspace threads, RT or not.
At first it was necessary to compile the realtime-lsm module to allow user programs to make use of realtime scheduling. In late 2006 or so (IIRC) rlimits-aware PAM became available which made realtime-lsm redundant.
I've used CONFIG_PREEMPT=y (along with CONFIG_HZ=1000) when compiling mainline kernels all along. My current distro of choice (Void) enables these by default in their 5.4 series kernels. I've never needed PREEMPT_RT for my particular use case.
AFAIK FreeBSD still doesn't allow users to run programs with realtime scheduling privileges (SCHED_FIFO or SCHED_RR), only root.
But I haven't been able to figure out anything that would indicate FreeBSD is better (or is better than what Linux was in 2016). The information is sparse, but it seems to me that it has a scheduler with _some_ support for realtime threads (when the timeslice is up, RT threads take priority in the scheduling algorithm), but not really preemption of non-RT threads by RT threads (ie., when a RT thread is ready to wake up, non-RT threads get kicked out even if the timeslice isn't up), and I cannot find anything at all about the kernel being preemptable by userspace threads, RT or not.