It's not just administration, it's everything else living on your server. It's the difference being surprised when package x doesn't support ubuntu and being pleasantly surprised when it does support BSD. It's the difference between being the most well-tested and well-supported configuration of all your tools and a niche thing that a couple volunteers got working.
Many of the things I did as a traditional university sysadmin long ago probably works on FreeBSD, and if you wanted to deploy a LAMP (FAMP?)/Django/Ruby on Rails/etc stack it would probably be good enough, but the world has moved on since then. Once you want k8s, ansible, distributed filesystems, HPC, scientific, etc. it starts to break down really quickly. Many of the things I listed above may work, but it's the less documented, less supported, more annoying, and more likely to break path. The extra time spent getting it to work on FreeBSD and maintaining it is not time well spent unless there's a very specific reason FreeBSD is better, just grab RHEL/SLES/Ubuntu and skip all the hassle.
FreeBSD has its place in very limited scenarios and where you have the engineering resources to deploy it, but it should not be the default choice for a production deployment.
I work at the FreeBSD Foundation. There are a couple points I'd like to make. First, FreeBSD support in Ansible and Salt is very good. There is work to do on K8s, but runj represents a great start and there are a bunch of resources available on how to use FreeBSD for cloud native. Last, I think your final point that "[FreeBSD] should not be the default choice for a production deployment" could be worded better. I gather your meaning is "...for a general purpose enterprise deployment". Assuming that’s what you mean, FreeBSD limitations that make it difficult for general purpose enterprise use is something I have heard and that I am personally involved in trying to improve. To me, that's different from "production deployment". There is a long list of production deployments of FreeBSD at the infrastructure and device layers - routers, VPNs, firewalls, storage systems, hosted security solutions, industrial control systems, CDNs, payment networks, and embedded devices.
Many of the things I did as a traditional university sysadmin long ago probably works on FreeBSD, and if you wanted to deploy a LAMP (FAMP?)/Django/Ruby on Rails/etc stack it would probably be good enough, but the world has moved on since then. Once you want k8s, ansible, distributed filesystems, HPC, scientific, etc. it starts to break down really quickly. Many of the things I listed above may work, but it's the less documented, less supported, more annoying, and more likely to break path. The extra time spent getting it to work on FreeBSD and maintaining it is not time well spent unless there's a very specific reason FreeBSD is better, just grab RHEL/SLES/Ubuntu and skip all the hassle.
FreeBSD has its place in very limited scenarios and where you have the engineering resources to deploy it, but it should not be the default choice for a production deployment.