This looks to be a theme in FreeBSD, specifically tweaking mbuf numbers because of exhaustion [1], [2], [3], [4] (and not to mention any posted on the freebsd bug tracker). The fact that you have options to tweak mbufs and limits in the first place just doesn't seem like a well thought out design -- in Linux you never have to specify skbuff (Linux's mbuf equivalent) numbers for any reason. I don't even know if my issue was hardware specific or just a FreeBSD-ism to do with mbufs, but it is a class of issue that just doesn't exist in Linux.
[1] https://serverfault.com/questions/335461/pfsense-mbuf-full-w...
[2] https://unix.stackexchange.com/questions/394876/how-to-fix-m...
[3] https://redmine.pfsense.org/issues/5553
[4] https://docs.netgate.com/pfsense/en/latest/hardware/tune.htm...
While you are right that it would be better to never need tweaking the number of buffers, all your links show such a problem caused by the same application, the firewall pf.
I assume that for some reason pf consumes more buffers than other applications, so it is likely to cause such problems. So pf users should preemptively change the default configuration.
I have never used pf, because I prefer the native FreeBSD firewall, both to pf and to the Linux firewall.
With the native firewall and with the many other networking applications that I have run, I have never seen buffer exhaustion, and like I have said, the mean time between reboots was well above a year.
FreeBSD and the other *BSDs have always been famous for not needing reboots, even after years of continuous operation. For this goal, avoiding memory fragmentation caused by dynamic allocation is essential. Thus static allocation for various kinds of resources might be necessary.