IMO that point is if either people demand support for the LTS (as said above), or if it takes significant share away from current stable.
As things presently are, the development of new features is slow enough (no shade at people working on it, there's a lot of hard problems to solve!). If it becomes the case that it takes a year or more for LTS users to get those new features, then I see a few ways that would harm the project:
LTS users are less motivated to add features when there's a lengthy delay between the feature being added and when they can use it, on top of the already sometimes-slow process of getting the feature added.
When a feature lands with incomplete ergonomics and a desire to improve it (e.g. async function in trait landing without the ability to return Send futures), LTS users are much slower to be able to try the feature and report back their experience with it.
It's still a plus if people go from not using Rust to using the LTS version, but if a significant number of current stable users go to the LTS, then that could slow down improvements to the Rust language.
If the Rust Project officially backs an LTS channel, then I suspect that a significant number of users might switch to it. But if the Rust project takes no part in it, and instead some interested 3rd party takes up that work (e.g. if Canonical wants to provide an LTS rust channel to go with their LTS Ubuntu releases), then I'd be less worried about that shift.
That's hard to judge. On the one hand I have definitely seen vibes-based reasoning that LTS is needed because "long-term" and "stability" sound exactly like the thing you'd want...
On the other hand people aren't actually that dumb, it's just learned behavior, and if they want to they'll figure out that "old-cruft-do-not-install" really is the LTS build.
As soon as people face some pressure to use an LTS, e.g. because updating anything triggers some compliance madness, and that choosing LTS comes at no immediate cost to them they'll find one and use it.
The fact that it doesn't even exist protects us from that.
And once someone makes a docker image that's named foo/rust:lts it's over anyway.
AIUI ferrocene already does offer legacy-support for their targets, but I don't know what exactly that entails.
But the relevant part is that this is 3rd-party, not Rust-branded, and they charge for it. So this a much bigger hurdle than just a name.
I'm not particularly convinced by either of these arguments. For 1), I consider the current delay in adding new features to be large enough that an LTS delay on top of that would barely make a difference. (For example, &own has been under discussion for over 10 years at this point (Add `&own T` by mahkoh · Pull Request #965 · rust-lang/rfcs · GitHub to https://github.com/rust-lang/rfcs/pull/4000), and yet I consider it a serious blocker to Rust feature development as a lot of features I'd like are most reasonably expressed in terms of it or are generalisations of it.) Every time I try to write a Rust program I get distracted by all the features I'd like to use but don't exist, which is probably why I end up on IRLO so often. It's hard to see an LTS meaningfully slowing down feature development when the features take so long to produce anyway.
For 2), such obstacles already exist regardless of the presence of an LTS: because unstable features are nightly-only and most people don't use nightly, it is usual for feedback on new features to be delayed until they are stabilised, at which point it is too late to actually act on the feedback. In other words, the existing stable Rust system is causing this problem to such a large extent that an LTS wouldn't make a difference. Again, Rust features typically take so long to stabilise that there would be time for multiple LTS cycles to come and go while the features are unstable (e.g. type alias impl Trait dates from 2018, https://github.com/rust-lang/rfcs/pull/2515, and is still unstable – and a lot of other Rust features require either TAIT or RTN to really be usable).
Objections to an LTS look really weird when compared to feature timescales that are this slow. If Rust released only LTSes, I doubt it would make a meaningful difference to the typical Rust programmer, because it's so rare for a feature that could be useful (to any given program) to have been added recently.
The standard library improves a bit more quickly than the language does, but I think it's reasonable to handle it separately (or even avoid using it altogether: it is common for the standard library to make trade-offs to cover the general case which might be undesirable in the context of any given program, e.g. Vec is a good general-purpose class for representing list/array-like things but any specific program that wants to store that sort of data would probably benefit from using some more specific type).
This has got me wondering: maybe an LTS should be #[no_std] (and perhaps exclude major parts of alloc and core too)? This would give a clear motivation to not use it for general-purpose use, and would considerably reduce the maintenance burden (by reducing the surface of bugs that might need maintaining); and the sort of projects that might benefit from an LTS are also likely to be the sort of projects that don't want to depend too strongly on the standard library. As mentioned much earlier, though, it probably wouldn't be very useful unless it could depend on an LTS LLVM (which currently doesn't exist).
Out of curiosity, how was impl IntoIterator for [T; N] conditionally provided then? Was it just that .into_iter() was masked and the desugaring hit a wall?