This is more or less what an LTS release is. The problem as I see it is that, as the codebases diverge, it becomes more and more work for the dev teams to support what is now essentially two different products. And especially in the open source world, it seems futile to expect unpaid or low-paid contributors to continue to do extra work simply because someone else's dev team doesn't want to put in the work doing updates.
Django takes great pains to ensure that this isn't true. We don't backport anything other than bugfixes and security updates to releases. It's not like we suddenly introduce a new feature into a previous release that's backwards incompatible with your current code. If you're on the LTS release then you can be happy in upgrading Django to the latest point release with all the latest fixes.
And the Django project has finite resources. It cannot backport security fixes indefinitely which is why we have the LTS release in the first place. If you want something stable: sit on that for several years at a time, or spend your time backporting any security fixes yourselves.
Unfortunately software is a moving target, but Django tries to make it easy to upgrade from one LTS release to the next. The upgrading difficulty often comes from third party packages, which is hard to avoid in any framework or language.
The best strategy is probably what many large distros like Ubuntu have adopted: designate only a few long term support (LTS) versions, and commit to supporting only those versions.
This is true of a number of frameworks I've worked with. If you want security, you have to constantly stay on top of the other changes that the framework makers implement, often "fixing" things that aren't broken, removing features, or changing the way things work.
I don't know how practical it is, but it would be nice to see a framework where security updates and feature updates were separate things. One could keep one's site secure through updates without having to debug formerly working things every few months.