The distros didn't invent those problems, it's what the users require, and the whole reason the distros exist. Because for a sysadmin, your software has a long term security support, or it's not going to be installed here.
Now I get that as a developer, you are mainly concerned with “day 0” and don't want to deal with years old versions. And that's all right. But as a sysadmin I am mainly concerned with “day 2”, and that means touching the working system as little as possible. Which means I want security fixes only—a LTS version. New features always require additional testing and companies tend to cheap out on that, so things are rarely updated often in production.
That's where the stable distributions come in. They provide security support for a lot of software the upstream authors don't. Don't tell them how to do their job, they've been doing it for 30 years, and don't make their life harder—Rust is already making their life hard enough by not supporting dynamic linking.
Security fixes are just as likely to break things and security fix backports even more so than new features that you don't use as end user. Especially when backporting over several years worth of internal refactorings, many of which are actually hard requirements for soundness fixes in the case of rustc and thus would need to be backported too.
The trouble is that it's not what users require. Users require three things:
Nothing that they like changes.
Everything that they don't like gets changed for the better.
Nothing gets changed for the worse.
Distros try to approximate this with "everything gets frozen in place, and only changes on big version bumps", but this isn't what users want, either. Developers tend to prefer approximating this with frequent releases, and undoing changes that aren't popular, but that conflicts with the distro efforts to meet user requirements.
But both of these are approximations to the underlying requirements, which are unique per-user, since each user has a different set of "things I like", "things I don't like" and "changes for the worse".
For end users, you are mostly right. And none of those things are requirements anyway, just desires. If they don't exactly get it, they are going to use the software anyway.
But for system admins, especially admins of critical infrastructure, this is different. Any change in business-critical, or even worse safety-critical, systems requires extensive testing, so any components that don't need to be updated never do.
Unless there is a security issue. Security issues do need to be addressed, and they need to be addressed quickly. The systems are critical after all, they shouldn't get compromised. But the update still needs testing, so the smaller the change to fix—or even just work around—the security issue is, the better.
That is where the LTS branches come it. That's why there are still RHEL 6 (released in 2010, nearing end of extended support) server at some of our customers, or, if they were upgraded four years ago when the regular support ended, they were often upgraded to already 6 years old RHEL 7 (2014).
Programmers sure hate it. Programmers want to use the available tools and in these cases they often can't due to old infrastructure. But there are good reasons for the infrastructure to be old.
This is exactly "nothing that they like changes, everything that they don't like gets changed for the better, nothing gets changed for the worse". You've defined the set of things you don't like as "security issues" (itself a rather nebulous term, since it's context-dependent), and said that these things need changing for the better (remove the security issue), but nothing else can change because that makes the testing harder.
But it's only a desire from sysadmins that this is the case; given a choice between a secure system and the business going bankrupt, or an insecure system that lets people do their jobs, businesses choose to run insecure systems all the time, and the sysadmins have to work around the problem - this is the origin story of firewalls, for example, since they protect against bugs by preventing you from connecting to a port that should not have been opened.
In the context of a business S/360 or a university VAX, this might well be the right thing to prioritise - security bugs may well be the worst possible class of bug for your system. However, in the context of embedded systems, security bugs are often fairly minor (especially if the system is not networked) - the scary bugs here are functional safety bugs, where the consequence of the bug is things like the system catching fire, or the brakes not working while the accelerator is jammed on.
I think you are missing a point made above several times. Those tests should be automated. That is what Ferrocene does for their certified tool chain. That is what we have moved towards at my day job, and while it was an investment, it has paid huge dividends. If you do that, LTSes aren't needed.
And you need these tests anyway, as you pointed out you need to test the security fixes too. And given the ever increasing number of CVEs, good luck relying on manual testing. It won't scale. Sooner or later you need to invest in test automation.
And as @farnz pointed out, usually security issues are less scary than safety bugs. The machines I code for at my day job are deployed on airgapped networks. So security bugs are of a lesser concern. Safety issues are way way more important.
Let's consider a worst case scenario from my day job: Should the machine run off the edge of a cliff in an open pit mine that is either very expensive (remote operations) or involves the loss of human life (operator in the cabin). So a safety issue that makes the code hang and the hydraulic motors driving the tracks continue spinning, now that would be really scary.
And this is why you have watch dogs, heart beats, physical separation of software that is safety critical and software that isn't, etc. But also automated tests so you find scary bugs quickly and early. And once you have a high level of automated testing you don't need to deal with LTSes, because you can be confident in your tests, and tests are now cheap (a few tens of dollars of runtime in a cloud for simulated tests on every PR, for relases: some lab resources for a couple of days against real hardware with environment simulation).
Do we still do manual tests for each release? Yes, you need some, just in case, and not quite everything can be automated. But we are talking a couple of days on one machine, rather than weeks or even months on multiple machines like it used to be a few years ago.