Thanks @masterofd for opening the discussion for this topic.
From a historic point of view, we had the 6-month-release cycle which we introduced with 4.3/4.4, and after 4.5 LTS and some further releases, we actually had to maintain 5 different stable versions, which is truly very difficult, considering all the minimum requirements (PHP version) where we also had some regressions due to PHP 5.2 support back then, so each backport should be considered and reviewed very carefully. Back then 6 months was considered too short to update, but 1.5ys seemed fine ;).
From a core team perspective, it’s already hard to developer a future version while fixing bugs in existing stable versions, having most of the core team doing this maintenance in their spare time. Meaning: Core devs need/should have all supported versions running somewhere to test everything.
Additionally, I have quite some extension authors that wanted/needed to keep compatibility with 6.2 LTS and 8 LTS, so it’s not just a core team responsibility and this needs to be kept in mind.
IMHO the biggest strength of the current release strategy for an agency lies in the predictability of the next LTS release: You know, you have a new project which will be finished 2 months after an LTS release, so you could use the next version instead of working with the previous LTS and then need to upgrade.
So, going back to your proposal, the biggest pain point I see for agencies / devs / admins is that the updates from LTS to LTS are still too “big”, too complicated and not as easy as just “clicking a button” (yes, I’m dreaming).
I think we’ve done better since 4.5->5.2, but still it’s not as easy as it could be. Also, core development still seems for me as “cleaning up” the big mistakes we did in 4.x branch (or did not know better back then), leading to massive breaking changes. The PHP7 bump / requirement is difficult for our projects to update from 6.2 to 8 directly (due to server updates in between). That also comes from the issue that there were (and still are) so many ways to do it in the previous versions while we go further in pushing “best practices”.
So: If the core gets better in fixing most of the currently open tickets, solving important conceptual problems and the update strategy is improved (e.g. code migration, DB migrations), I think agencies could benefit from easier updates, instead of “staying in the past” and that should be the actual goal.
If people stay with an old TYPO3 version or a 5ys LLTS then extensions will be a problem (most of the time, I’ve seen that) and that won’t make the update easier to the next-next-next version then.
Basically my message is this: Let’s look at the root cause(s), not a symptom why this is a problem for agencies / admins / hosters.