Characterizing this software feature as an "attack" or "backdoor" is pretty hyperbolic. In order to abuse multiplexing, the adversary needs local code execution ability, by which point you've already lost.
Some would argue that getting someone to run a script is difficult, but we found that about 10% of developers want to be helpful and are not cynical enough to presume malice. They will run the script which will happily drop a ssh key, fire up sshd as the user, create an outbound connection to a passwordless shell-less VPS node and then we are that developer and can piggy back all their connections. Some developers are devops, so they also have prod access. Some places have passwordless sudo, too. In some places, you don't even need sudo, as the posix permissions of applications are sub-optimal.
If you try this, the script should have an obvious problem that requires running it to see. The developer/engineer will feel good that they helped you solve a trivial problem and you will have whatever access they have. Obviously get written permission for this type of pen-test with all the steps clearly documented and approved. Most important, ensure management agree to NOT shame the victims of the test. Get them to participate in the re-engineering of your network to harden it properly without adding excessive friction.
If I phish you and you run a script, but multiplexing is disabled, then I have to take a few extra steps on your machine to capture passwords assuming you have passwords set on your ssh keys. It also means I have to initiate a new connection rather than using your existing ssh channels. Depending on the environment and your laptop configuration, this may or may not increase my risk of being detected. This of course highly depends on what level of logging and remote monitoring of your laptop is in place.
Assume Breach mindset that Microsoft developed for instance - in case you are intersted to learn more. There is an entire domain/world of security engineering that starts when the initial compromise has happened. And it does/should not mean the adversary won, just because they have code execution on one host.
Heck, the attacker prefers a certain SSH config, the attacker could just change it. Even if you disabled the feature at compile time, the attacker could just replace the SSH command in your shell with their preferred version.
This is just disabling useful features to maybe cause minor inconvenience. I find it about as interesting as telling someone to pull out the power cord of their monitor to increase security of their login prompt screen.
Coinbase recently had a very interesting article/blog post about something similar, how adversaries gained access to engineering hosts and how they detected it.
Of course how much you lock something down depends on the critically of an asset and so forth. E.g. in certain high security facilities slight variations of your monitor example are applicable.
It’s useful in pivoting from a foothold attack at the boundary (e.g. Chrome zero-day) into the crown jewel backend which could be totally isolated to reduce the attack surface, but if you connect into it from a compromised host, this provides a convenient and hard to disable vector to piggyback onto the connection.
If there was no way to piggyback the session, even owning the developer’s terminal doesn’t gain you access to a secure system which has multi-factor authentication using a hardware token.
Depending on how big you are and how much security is a core competency, even at this point it's important for your system to be architected in a way that can slow the attacker down in order to give your blue team time to respond.
Ideally you will have built your system to have multiple layers of defense. Reality is somewhat less ideal, but it's still valuable to discuss how to harden against amplification/persistence techniques after the initial breach.
Though I suppose if a key has a password on it, this attack might be useful.