No BBR yet.
The RACK stack is in 12.0 and provides many wanted benefits outside of BBR's proficiency against channel loss. I can blog or something about how to build and use it if interested.
I run a clutch of Dells, on FB and they're moving to Debian for other reasons, where I get BBR. I would have fought harder to retain them on BSD if we'd had signs the network stack was getting the same amount of attention.
When VJ moved to coding against Linux instead of BSD, I think the writing was on the wall. When Grenvilles team in Melbourne disintegrated, and that source of TCP energy dissipated, the writing pushed the wall over. (I think they moved to netflix)
There is a competent team working on TCP at Netflix, led by Randall Stewart. They collaborate regularly with VJ and his Google team and the IETF tsvwg.
We run the BSD core because we're a three person research activity run by dinosaurs who had BSD systems in the eighties and stuck to them all the time since.
Now we are exposed to things like iscsi and ceph and Hadoop and elk stack.. and it's just too bloody hard to survive in ports on freebsd for this stuff. It's become corner case.
BBR is a case in point. Data fetch to the home nodes on bsd from Asia, Europe and the USA (we're in oz) was two to three times slower than via a Debian node because of it.
BBR is a very fast recovery algorithm. Its not always very "fair" to other forms of TCP. BSD and Linux both have kernels which allow selection of different methods of backoff. BSD has cubic, and some other choices, at this point only Linux appears to have the BBR method integrated. It is in test in the BSD stack (I believe)
If you have sole use of a host, and want to do long-distance file transfer, with loss, BBR can sometimes get you things faster. If you're in a Data Center (DC) BBR can cope really well with dumb switch packetloss, getting you significantly faster recovery.