For ultimate flexibility, I would think it's valuable to have the major part of the Python code simply read from STDIN and write to STDOUT. ...snip...What you would need is a low level wrapper: some code that finds and opens the tty port, and redirects it to STDIN/STDOUT, then calls the core code.
I think what @ShapeShifter has been suggesting is to write some code so that STDIN and STDOUT for my Python program piggy-back on top of the connection to ATH0 established in the startup process.
But if I were to do that I believe I would lose the ability to have two streams of communication.
The only (?) linkage between Linux and Arduino is via ATH0 on the Linux side and Serial1 on the Arduino side.
In my way of thinking so far having the two streams of communications has always seemed important - or at least very valuable when they are available "for free".
I get the impression from your comments that your mindset favours the Arduino code starting the Python code. But my mindset is very much the other way round. What I have in mind is that a user can write the exact same code for a Yun as for an Uno - only needing to change Serial to Serial1 with the text editor.
I would also like to think a user who had developed a simple Python program to link his laptop to her Uno could use that code unchanged on the Yun - just changing from (say) ttyACM0 to ttyATH0.
As far as starting the Python process on a Yun, what's worse: making the new user deal with the Linux command line to manually start the Python process every time they want to run? Or simply adding a line of code to the beginning of the sketch and not have to worry about it after that?
I guess I just don't like the idea of hard-coding a serial port name,
But this assumes they are more familiar with Arduino than with Linux or with PCs and Python.
To be perfectly honest, if it had been my decision there would never have been a Bridge system. I would have considered it perfectly reasonable for people to use Serial1 given that they are already completely familiar with that sort of thing when using an Uno or Mega.
But you are looking at it from the point of view of an Uno user talking to a PC over the USB port. The bridge is not necessarily designed for that, it is designed to simplify the transition of someone moving from an Uno with an Ethernet or WiFi shield who wants to make network connections from the sketch. You want to use the Arduino processor to communicate with the Linux side like it is PC. The Bridge is primarily designed to allow the Arduino processor to talk to other computers over the network. I think that's why you have a philosophical conflict with the Bridge philosophy.
See also the law of leaky abstractions.
The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time."
In the OpenSource world things are made much more complex by the almost universal unwillingness to write comprehensive (or any) documentation. If there is "documentation" it is one or two examples rather than an explanation of what can and cannot be done. The "cannot" is often the most useful information.