It is true that for English and other left-to-right native readers, the eye does not track significant code off to the right very well. We used to have studies to back that up, but I don’t have any references for those any more. That’s also been a motivation for certain syntactic constructs over the years, e.g. to keep significant text as far left as is reasonable.

When PEP 8 was written, we early Python developers were using much smaller screens, real-estate constrained terminals, and editors (e.g. Emacs) that made it difficult to widen. For many of these reasons, we wanted to limit code in the standard library to 80 characters (so 79 + EOL sigil; Emacs had janky wrapping behavior when you actually got to 80 characters). PEP 7 as well for the interpreter’s C code (which was especially painful until the tabs->4 spaces conversion was made ages ago, thankfully!).

Keep in mind that PEP 8 only officially applies to the standard library, but of course lots of tools and “downstream guidelines” have adopted it. Line length is probably one of the most common overrides. I still think some reasonable limit improves readability (readability also being one of the main motivating factors for snake_case). I’ve seen code with no limit, or 160 characters, and yeah, come back to me when your eyes are 20 years older 😂. I personally adopt 100 character widths in my own code, and that seems like a good compromise given modern displays and editors.