I don't think anyone is saying to use long lines wantonly, just that they aren't such a scourge as they are made out to be. Most lines of code, I find, are naturally only a few tens of characters long, and I can't recall a single instance of seeing two 80+ character lines adjacent to one another. You can argue for some other points, perhaps, but I just don't think readability is a good reason -- certainly not if the alternative is to artificially format it in a way that is, arguably, just as unreadable, or to start abbreviating code structures and object names (which I don't think either of us would advocate, but which some people would undoubtedly do) to save characters.
You bring up a point of how other tools might present the source code differently, and that's true. However, I would say in response that I see this as a presentation issue, and something which the tool should handle better. I evaluated, for work last year, some tools we could use to pretty-print code as a PDF, and none of them handled long lines well -- some by truncating, some by naively word-wrapping with no attempt to preserve some kind of formatting, others by scaling the font size relative to the longest line in a section and the output page width. But its a tools deficiency. I shouldn't have to think about what some third-party tool does with my code, other the standard tool chain. Of course we can agree that one should consider specific requirements of specific tools if those tools are important to us, but working around tool limitations is a problem regardless because then we have to know our entire toolbox up-front to plan accordingly, or simply settle for the lowest common denominator.
Specifically you say:
It's not hard to make your programming literate so it is understandable in any of these common formats as well as in your text entry tool. Using long lines is not one of the ways to do that.
And I would argue just the opposite -- simply saying without specific merit or cause that all lines longer than an arbitrary limit are verboten does not aid overall readability. Remember that the alternative to "can't use, ever" is not "must use, always", but "can use, sometimes". I further argue that the natural structure of code, at least in any of the languages I use, is such that even the mere opportunity to create lines longer than 80 characters is so exceedingly rare (laying aside ridiculous streams of unrelated statements because C++ et al allows me to) to be almost a non-issue.
Sometimes the most legible or 'literate' thing to do is to allow for an occasional long line, rather than to force some unnatural structure upon it.
There likely is some reasonable upper-bound, but I'd wager its quite a bit north of 80 characters -- even the box I'm typing in now, on a website, in a frame, with margins at the side, in an application window which is not fullscreen, all on a not-particularly-wide 1080p screen, displays about 120 characters comfortably in a fixed-width font.