At my current employer, and the previous, we used FreeBSD for its base OS, and then most of the services we ran were our own proprietary code, built with in-house patches on top of an open source language. We didn't and don't tend to upgrade the OS unless a release (or a patch) fixes a specific issue we're seeing, or is a security issue in things we actually use, but new hardware tends to get the latest OS (we're currently installing 10.3, but may consider 11.1 now that it's out; we do have a couple machines running 11.0 because they need the per disk io threads and fixes to directio that i think were in 11 as well). When we run into problems, we'll look to see if it has been fixed in upstream, and see if we can apply that to the whatever release we're currently using. If not, we try to fix it ourselves, and then offer the fix back; but we're happy to run with our version of the fix until it makes it upstream.

We've had pretty good luck with upgrades not causing major issues, but we did have some trouble with mrsas drivers for a while, and the VM change in 10.x where pages are marked inactive and can get swapped out without memory pressure caused us a lot of trouble until we figured it out.

The benefit of the lengthy release process is that the releases are pretty solid, and once a system is setup, we don't have to touch it. Also, because FreeBSD doesn't change for the sake of it, we don't usually have to worry about some systems being on 9.x, some on 10.x, and some on 11.x; we just are sure to build software either on the hosts themselves, or on an older system, so it'll run on all systems.

Edit to add: The most frustrating thing for me are the many Bugzilla entries for issues that I'm having, with patches, that are sitting there for years. For example this one https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=25986 which was open for 14 years before it became CVE-2015-5358