Thanks everyone for your feedback! I feel more confident moving forward with my updates now 
While researching this, I also came across this other package-dev-related topic (Should a new package I am working on test agasint 17.0 or the latest release of 17? - #13 by mistyn8) with more interesting multi-version debates.
I think that at this time my strategy will be for my baseline packages (which are referenced by many of the other packages and are primarily class libraries providing useful models, calculations and extensions), I will try to keep as multi-targeted as possible just to make referencing simpler, and if I start to bump up against umbraco-version-specific issues, I’ll create new majors of those as needed.
For the more complicated packages, particularly ones that have any sort of back-office components, I’m going to go with the major version strategy that you all have mentioned. However, I don’t know if I’ll be devoted enough to keeping up with every STS version, perhaps only the LTSs, since those are the ones that I use for my clients. This might result in weird jumpy version lists, but I agree with many of you that having your package version number somewhat match the Umbraco version number is the least confusing to consumers of the packages. (I easily recognize that if I have a v13 site, and the latest package version is “17.2”, I’m not gonna update. This is way less clear if the latest version is “4.0.2” and my current package version is “3.9.6”…)