Every other reason on that dialog does double duty: it serves as guidance for the reviewer by suggesting potential problems they should look for in the edit, and it serves as guidance for the editor should their edit be rejected.
But the text on the last reason exists only for the reviewer. The editor will see what is typed; the text on the dialog is entirely for guiding the person rejecting the edit. To this end, it should endeavor to constrain the potential reasons that may be entered: certainly we don't want edits rejected because a reviewer disliked the editor's username, or lost his keys!
The current guidance is simple: explain why the edit made the post worse. A quick scan of the reasons being entered suggests that this is more than sufficiently flexible:
wrong use of quote-formatting, adds noise
Code blocks should only be used for code, not "python" or the problem description, and the emboldening is unneeded
Too insignificant to bother with.
this is just polishing turd.
...to list an arbitrary few of the 700-some rejection reasons entered over the past 30 days. Note that the most common reason among these is some variation on "abuse of code formatting", which is a great reason to reject an edit.
In short, I don't feel that further generalizing this buys us anything; no amount of discussion on meta can replace guidance that's ready at hand in the UI, and your suggestion weakens what little guidance now exists for that last reason, requiring a reviewer to gauge the usefulness of an edit (a notoriously controversial concept) rather than simply examining it for harm.
I would be open to suggestions for improving or further clarifying that existing guidance however.