As far as the version numbering goes, might I point to your own description of the versioning system you use?
Version 2.4.2 is a z release, which your described versioning method says should contain “urgent bug fixes, security or maintenance changes only”. In fact, it contains a new feature (sorting by author), and thus falls under at least a y release. I would describe the new function as a “minor enhancement”, consistent with your stated versioning system.
Dropping backwards compatibility of any kind is only mentioned in the x version identifier description:
A major change *might* mean it can break backwards compatibility but I strive to not do this, if at all possible. However code “bulk” is equally something I am concerned about so will often provide backwards compatibility for some time before finally phasing it out in a major release.
So it seems that, at least in 2016, you agreed with me that breaking changes like raising the required version of a dependency (WordPress, PHP, etc.) should come with a major version bump. If your versioning system has changed and that post is simply outdated, then I rest my case on this front.
I do, however, think it’s a bit odd to offer such a relatively simple plugin that cannot run under every environment WordPress itself can. Maybe I’m biased. I do steward a Python project that runs on both 2.7 and 3.3+, even though that causes some code headaches, but I put up with them because I think it’s worth supporting users who can’t upgrade yet. And in this case, the overhead to support PHP 5 really isn’t that big. It’s all of a five-line change. (It would be a seven line diff if I used intermediate variables to store the uppercase versions of the strings to compare, but I see no reason to go back and amend the pull request unless you actually want to merge it.)