The problem is that these topics are related. The current situation is a trade-off between wishes of various groups and what can be achieved with the available manpower.
So, if the consensus is that the minor versions (the steps towards a new LTS) cannot have breaking changes and can’t remove deprecated code then the available manpower isn’t capable to continue with the current release cycle. Development will slow down or there won’t be LTS versions or …
There is another topic about EEELTS versions. Sure we can support every release for 20 years. But with the available manpower that means we have to drop something else. Development will slow down or major versions will be released only every 10 years.
Another use for the minor releases is that there is a feature freeze for every minor release which provides some time to test everything. In the past we were busy making feature for a long period and then had a longer feature freeze period with alpha and beta releases. The sad truth was that hardly anyone (thank you very much to those who were the exceptions!) tested these. Most bugreports came after the release and especially after the x.y.1 version because many people waited for the first bugfix release as they expected that the x.y.0 version wasn’t really stable and the most annoying bugs would be fixed by then.
To end with a lighter note; I really liked how Mathias’ answered when an agency requested a large feature after a presentation: Cool, we’ll do that, just send over a team of developers.