It’s important to differentiate what people say when they mean LTS. There’s roughly a split into two groups.
People that want a stable focus point. For example, you want a release that can be used as a base for software shipped with a certain distribution. These people need a cut-off point where they stop using new features and can be half-way sure that a wide base supports this version of Rust. It’s kind of an in-between of a service to distributions and users. This establishes something that Rust is currently lacking - forward-compatibility on an ecosystem level. An LTS could lead to a point where many base libraries agree on supporting Rust LTS, and only custom products opting into newer versions. Tuning this to the cycles that distributions have is probably the best way to do this.
People that need long term support for business reasons. For example: you produce a certified firmware. They basically want their toolchain in an icebox. They don’t necessarily care for “the official LTS version”, they care for not upgrading the version used in a product, as any upgrade would incur certification costs. Also, usually, the time frame for this is nothing that a FOSS project can reasonably provide. It only makes sense as a commercial service, IMHO. A usual model here is though that people take the official LTS version as long as they can get and then get a support extension.
 Sorry for the advertisement, I happen to offer that.