Sure. From the Spyder-Docs repo I linked above, see, for example, spyder-ide/spyder-docs#296. In particular, see this sentance as an example of a longer one in which relatively few changes were made, but GitHub’s highlighting makes very clear what those are (similar to the example in your comment on the other thread). And for the opposite case, see this for an example of a sentance that was almost entirely rewritten, but GitHub still accurately shows what parts were and weren’t changed. With hard breaks, this won’t work well for the former, and is almost completely impossible for the latter. (Of course, if viewing the files themselves, rather than the diffs, they rendered and wrapped by GitHub anyway regardless of the source wrapping).
You might find my reply on the other thread of interest, as it addresses a lot of the points in the post you linked (which I’d been meaning to reply to), as well as the above.
If you deliberately toggle word wrapping off in your editor for reST files, then yes, sentences would be pretty long, but I don’t really understand why you would realistically want to do that. For prose text, making your editor pane 80 characters wide, or any width your eyes prefer, will produce the same effect as hard-wrapping at that specific character threshold without all the work and other costs of actually baking it into the file.
As for GitHub Mobile, I can’t speak to that as I’ve never used it (except to check rendered output in mobile browsers), but it seems like a GitHub bug. If that is the still a problem, it is unfortunate and hopefully will be fixed soon, but I’m not sure that specific edge case justifies the other continuing costs of hard breaks elsewhere—I would be curious to hear of others, though. And I’d certainly hope that others aren’t spending hours every day on mobile writing, editing and reviewing PEPs, as I do on desktop—I’d be worried about a lot of other barriers to usability in that case, though if would certainly appreciating hearing how common this is in practice.