It's pretty common for package managers to make a hard dependency on the OS major version at times. Some programs needn't do this (e.g., Tidings has been unreleased for a long time and yet it "survived" many major OS upgrades) but others may benefit from this.
Depending on a specific package because you know it will have all the dependencies may not be possible on major OS upgrades as the repository may have changed and that package may not be there any more. Moreover, if you're a developer, it is simpler to set a baseline and just state that in your application - e.g., a SFOS 3.4 developer will probably not know what SFOS 1.0 had bundled, so it's just simpler to make the program compatible for a current version.
What you describe is a pattern used in OS's/distributions that support rolling upgrades, and even in those cases there are certain states where you won't be able to upgrade any more, one of the most popular reasons being that packages simply change or disappear from the repository. In practice, if you forget to upgrade such OS's/distributions for ten years, don't expect that the package manager will happily bring you to the present time.