The problem with the serial cable is that if they do it wrong, their wallet is exposed to everyone. They end up with less security than they thought they did, and the false sense of security be worse than not having had the option to begin with (they would've relied on something slightly less optimally secure, but with less user error).
Having done serial comms for a very long time I don't think this is a serious issue. I think at one point you expressed the fear that someone could unknowingly leave a getty process running on their serial port, making it a conduit where someone on the other side of the "moat" who breaches the security on one end could use the serial connection to log into the machine.
I don't see this as a realistic risk - first off, it's easily detectable by your application, you should have no problem finding out if any other processes have your desired port open. Second, assuming you didn't detect it, the constant error message traffic generated by the getty as it complains about all the data it sees would clearly disrupt the communication so bad that the operator would notice something was wrong right away, and third there's many other obstacles, not the least of which is having to hack the owner's password through an interface that is already very hardened against brute force hacking, never minding the fact it's already slow.
You are clearly more knowledgeable on this stuff than I am. You seem to think this idea is DOA. I didn't think it was so crazy, but that's why I put up what I thought was a fairly significant bounty (I'm sure some grad student out there would like the challenge and make some money).
I have no doubt that someone could put together a proof of concept and get
some data to go through
their two computers' audio link. But I think it's totally unrealistic to expect this to be reliable and more practical for even expert users as compared to RS232. I think I am saving you lots of time and frustration by just saying don't mess with it.