Most people have or should have already moved to 14. Some people can't, for example if they have binary kernel modules; we provide stable kernel interfaces within a major version but not between versions.
From my perspective though, the most useful thing about doing legacy branch releases is that it gives us a chance to practice the process. Mike Karels was supposed to be the release engineer for 13.4 -- his first release since BSD 2.x -- before he died on the way home from BSDCan, that is.
A number of people do not care enough for things getting better. The OS they are running is fine, it solves their problems and does not have gaping holes. But they do care a lot about things getting worse: something breaking during the upgrade, something degrading or becoming incompatible, and requiring more work just to get to the previous position. So an upgrade has basically no upside and a significant possible downside.
I'd say that you either live in a rolling mode, when you spread small-scale fixing and adaptation efforts over a long time, or you stick to a particular release and only apply security updates, and never upgrade, but instead build your new iteration from scratch using new versions of everything.
There are some people that like the stability of staying in a single branch for a longer period of time. Same as for example people staying on RHEL 8 vs RHEL 9 or Ubuntu 22.04 vs 24.04
For general purpose systems it doesn't make much sense to lag a release, the amount of breaking change is pretty minimal in FreeBSD these days and it is fairly common to run -CURRENT (main) in production so there aren't a lot of hidden dangers in a .0
Old school appliance vendors appreciate the old stable branches where they carry a lot of local changes.
Not recommended. We have backwards compatibility but not necessarily forwards compatibility within a stable branch; running a 13.4 userland on a 13.3 kernel could break horribly.
(My guess is that it's probably fine, simply because not much has happened on stable/13 in the last 6 months. But it's not uncommon to have e.g. new syscalls MFCed.)
I never said that it's recommended, just that you could do it.
Actually I completely agree with what you say. I've been forced to try at work a few times though, due to stupid reasons, it has worked out every time except once. Exactly due to what you mention.
The one time it didn't work out things exploded beautifully, so the stupid policy that we can't reboot is now scrapped. :-)
There are also security errata which require a reboot. Maybe if your device is not connected to a network you can get away with not updating / rebooting. But in 99% of the cases having a 700+ days of uptime is not a good thing anymore.
