Intuitively, I would expect the latest version to be selected according to semantic version for repositories following semantic versioning. See Setup Node.js environment · Actions · GitHub Marketplace · GitHub for example, which incorrectly advertises v1.4.5 as the latest version rather than v2.3.1.
I think that when you created a release also matters in terms of order of appearance. I remember having experimented this problem when adding releases all at once to a repository for which I didn’t previously create any — they were shown according to creation date, and since I didn’t add them in the right order, they were not in SemVer order.
This doesn’t make sense to me assuming that semantic versioning is being used. The first time you have to go back and patch an old version it will suddenly jump above the latest release and become the default “lateset version” recommended by GitHub Actions. Users that are in a rush or not as conscious of versioning schemes are likely to accept the misleading default and use the old patch version. For projects that don’t use semantic versioning, I think using the release timestamp is a reasonable fallback heuristic, because there are too many cases to worry about and not many big projects that don’t use SemVer.
I’m not sure if this also applies to edits resetting the revision, I think it only affects them by creation date. But yes, I agree with you that it doesn’t make much sense, and I was also disappointed when I discovered that, for it looked really bad to have releases out of order.
Most version schemes are designed to be asciibetically sortable, and in any case even using a timestamp as a tag won’t work in this case, since its the creation date that counts for ordering.