I just did some testing and I believe that this a historical artifact of how the "Improve" button used to work in the Suggested Edits review queue, before the review system was revamped in 2014.
Back then, the "Improve Edit" and "Reject and Edit" options would be combined into a single option, known as "Improve", and that option would always load in the new suggested edit for the reviewer to improve. They would then be shown a choice of whether the suggested edit was helpful or not, which would indicate whether the subsequent changes on top should be an improvement on top of the suggested edit, or if the edits should be applied but the author shouldn't receive credit or reputation.
I was able to piece this together from the following facts, using my browser's developer tools:
I saw that the review type ID for the "Improve Edit" button is 5, the same as that of the "Improve" button from when the system was originally designed. (I can't say this for sure, but as Approve is 2 and Reject is 3, but Reject and Edit is 19, and the overall order of review type IDs seem to be in the order the buttons were first introduced, this seems to be the case.) This means that today's Improve Edit button is loading in the same form as the past Improve button.
After looking through the series of AJAX requests made by the page when clicking the button, it seems to be loading in the exact same editor page that would be loaded when editing a post (
/posts/[post ID]/edit) (but adds more review-related features which I'll get to in a moment). The system normally blocks external access to this form when there's a pending edit: users who load the page while there's a pending edit will be directed to review the edit when they click "edit". If the editor form is loaded anyway, it thus makes the assumption that it's being loaded in from the review queue's Improve [Edit] option and thus preloads in the suggested revision. (As you point out, that assumption is not always correct.)
Looking through the DOM of the review page, it seems that the old "suggested edit was helpful" checkbox is still present in the DOM, and checked by default, but is now hidden with CSS. (Which furthers my first point, that it's still using the same form as the former "Improve" button.) As a test, I suggested an edit while logged out, then used Developer Tools to unhide the checkbox, and unchecked it. I got the same behavior as you: the edit was automatically rejected as an edit conflict, but the suggested edit was applied. (It also listed me as reviewing it as "Edit" - there's another thing added to record a review on saving the edit.) It seems that unchecking that box triggers the edit conflict logic - and this is what was used to physically reject the edit by Community in the past.
As far as why unchecking the box triggers the "edit conflict" message: keep in mind that prior to August 2014, edit rejections by Community for any reason didn't have a message attached to them - they would just show as rejected by Community with no explanation. As the outward behavior in both cases (unchecking the "edit was helpful" box and actual edit conflicts) was the same, they implemented the uncheck logic by intentionally triggering an edit conflict. (This also explains why before the edit review system was revamped into the modern set of buttons, no edit rejected by Community would count toward editing bans - as it wasn't possible to differentiate between those two cases.)
tl;dr: the reason why this bug is happening is because of historical logic from the way the edit review queue used to operate, plus the not-always-true assumption that users can never access the editing form while there's a pending edit.