So the answer is that it is not possible to change a payment method in core without creating additional financial transactions.
Background: a decision was made by some with decision powers that every edit should produce such transactions so this is working exactly as designed and the argument given is that this is in order to be compliant with accounting standards. The odd thing is that of all the projects we render IT services for every single CA considers such transactions noise and not helpful at all. I hope at some point we are able to revisit this and be allowed to simply delete payments [possibly with a permission level so a superadmin would need to authorize it] - it's completely reasonable to be able to delete transactions that never happened but were entered accidentally b/c of a default payment method e.g.
Your current options: a) via the GUI the only way to 'fix' this is for staff/admin to delete the entire contribution and re-enter it. b) via the Database: if you have access to mysql like you do - you can remove the extraneous transactions across a number of tables. I did one for a client this morning. Before you do this track a couple of contributions/'refunds' all the way through through all financial_ tables to familiarize yourself with the structure.
Another way to look at this is: admin/staff are allowed to delete all financial transactions - 3 in your case (by deleting the contribution) but are not allowed to delete a subset of the 3 - i.e. 2 in your case; whereas if you have permissions to delete all contacts, you can delete a subset;
PS - in credit card payments when mistakes are made a payment can be voided after it has been authorized but before it has settled. Such payments do not show up on a credit card statement. Perhaps we can adopt that concept and allow payment mistakes to be corrected for a limited time, as most mistakes will be caught (almost) immediately.