You're offering hypothetical, worst-case whataboutisms. In the real world, any shop that isn't stupid will use defense-in-depth to protect the unupgradable bits.
Security is about risk profiling and making good tradeoffs between things like cost, convenience, timeliness, and confidentiality/integrity/availability. All computer security is basically futile because in the face of a sufficiently motivated attacker, so chasing perfection is wasting your time.
If you're doing home security, you don't use armed guards and reinforced steel doors, with the defense of depth of an extra-secure bulletproof safe room, because the security would cost more than the value it provides. You might use a good deadbolt though.
The same goes for computer security. In combination with certain security approaches like air gapping, a technically insecure out of band management network can quickly become a dramatically less plausible means of being exploited compared to say - unsexy things like email phishing attacks. So replacing all your servers with ones with supported out of band management systems can simply not be a reasonable priority to have.
Whatever. Imaginary paranoia strawman that is the wrong kind of paranoia: the unactionable, ego-based kind. You completely ignored defense-in-depth approaches like airgapped systems and adding additional layers and protections to mitigate your hypothetical non sequitur. If you fail at these then you don't actually understand security and are just arguing without a leg to stand on.
But sure! If I have a server I currently use OpenSSH to connect then I certainly _could_ airgap the machine and require anyone using it to be in physical proximity to it. But don't you think that might be unrealistic in the vast majority of scenarios?
If you have a server that you can't secure properly because it only supports obsolete, known-broken cryptography, then yes, absolutely, you should airgap it or find some other way to protect it.
Or you could... not do that... and expect to be hacked, over and over.
But the airgap scenarios are very real, and they make it more difficult to just go online and grab an old ssh client that will do the job.
It seems that the argument for removing support for the old algorithms involves the need to maintain them in the new releases. This only becomes a problem if/when the code and/or regression testing is refactored. So eventually the effort required to remove support becomes less than the effort needed to continually support the old algorithms.
The OpenSSH maintainers can of course do anything they like, but removing support for legacy algorithms is basically passing the problem down to (probably less capable) users who are stuck without the ability to connect to their legacy systems.
You do recall that the source control doesn't disappear, even after support is pulled? I've built ancient versions (specifically in case of SSH, to get arcfour for whatever convoluted system); this wasn't a simple operation, but feasible, even for someone with just a general knowledge of SSH and its build toolchain.
Maintaining code also takes time and effort: smaller codebase, effort better spent. If it's too costly to just keep an ancient version of ssh around, and even too costly to pay someone to do that for you, how's it suddenly NOT too costly for the maintainers? If you're going to the lengths of having a special airgapped network of legacy systems, how do you NOT have the tools to use with those systems?
I think you missed my remark about the inability to pull an old version from within an airgapped environment. It's usually still possible, but the level of difficulty can vary depending upon security requirements. Imagine a security officer refusing to approve the introduction of an older and insecure program into a secure environment.
Otherwise known as “security”, yes