I’m afraid that, were I your team-lead, I would, rather decidedly, vote down your change, and not permit it to move forward into production. And here would be my
two three reasons why:
Although the existing code might “offend your personal sensibilities,” it is nonetheless obvious as to what it does. I can, using nothing more than my two eyeballs and from this (looks to be, rather extreme) geographical distance, be pretty-darned sure that it works. (Furthermore, you are not reacting to any outstanding bug-report that suggests that it does not work.)
Your “replacement” code, on the other hand, is not “visually obvious.” At first glance, and the second and the third, I have no idea what this code is supposed to be doing. Thank-you for providing test cases, but once again, I cannot be sure that these test cases are complete or exhaustive.
There is business risk associated with your “gratuitous” change, but without any apparent business justification.
Yes, I would make a mental note to be sure that, henceforth, you always had enough assigned tickets to deal with, that you nevermore felt that you felt that you had enough spare time to indulge any temptations to “distract yourself with things that ‘you thought’ needed to be ‘improved about’ stable production code that was in service.
I am, as usual, quite sure that “the downvote daemons” will jump-on this opinion ... as they have done with so many others ...but in my defense I would simply say that it boiled down to a pure-business decision: “In some ways, we all work in a sewer. We can’t be making decisions based on smells.” Change, itself, is “the bugaboo” here. The <<business risk | business cost>> intrinsically associated with any change at all (especially to “active” code such as this ...) is so extreme that it must never be undertaken lightly.