Re: A big mistake, this
I would say it is entirely sensible, if FreeBSD *must* continue their current scheme, to assume upgrading to the next point release of the current branch, and the following release (one louder) in that branch if not.
If point releases must remain, a system is on 13.3, and up to 13.5 is available it upgrades to the next point release. At that point if you wish to explicitly jump ahead I'd accept parameterising that is a good idea. It should be the least effort, and the least surprise.
Personally I'd use OpenBSD as a model[2], it has sane defaults. Junk point releases entirely, stick changes in a patch or push anything else to the next major release. Just 13.0, no .1 though .5. If it's a security or particularly important issue, it's a patch, otherwise the functionality goes in the next major release. Heck, OpenBSD is the *only* operating system I would be comfortable running on -current.
Junking point releases would (should) also lead to longer support, particularly for pkg, whereas at the moment it's necessary to upgrade point releases in relatively short time frames[3]. Here, I'm holding FreeBSD to a higher standard than OpenBSD, because OpenBSD is largely rather useful with just the utilities in base and FreeBSD.. isn't[1]. FreeBSD I expect to run more servers and make an attempt at being a desktop environment, and the fact without fiddling around it's necessary to upgrade point releases uncomfortably often and then run the risk a pkg upgrade breaks something is unpleasant.
I do like FreeBSD when it works well - recently I've used jails to maintain multiple instances of Unbound and it's far cleaner than any other solution I could devise, but it also rather frequently annoys the snot out of me by assuming knowledge or not using sane defaults.
[1] Sure, you could undoubtedly just use it as a firewall, but then why bother : there's OpenBSD that's explicitly designed to do that.
[2] I will concede that OpenBSD's support cycle is not long either, but because the way I find to use it reliably is to stick to base functionality, and because release upgrades are with very few exceptions extremely reliable it fills me with far less trepidation than a FreeBSD update.
[3] I'm sure there's ways around this by maintaining your own repository and frequent compiles from STABLE or whatever, but this is yet more hassle that shouldn't be necessary.