There are quite a few different things you can "tune" a query to "optimize/minimize": duration, IO, CPU, Memory, locking, etc. In your case it would seem that you have reduced IO (likely from eliminating nested loop activities) but kept duration roughly the same (likely from an increase in CPU usage to do HASH joins, but that is just an educated guess since you didn't provide the actual query plans).

If the CPU usage is higher on the new query then you can make a secondary decision that you want to minimize that, and thus revert back to the original.

Another consideration is concurrency/locking. One plan could cause many more blocks to occur than another and that could be the thing you need to minimize in a busy environment.

Good tuning takes a LOT of knowledge, experience, some art and even sometimes just plain dumb luck. I have 40000+ hours dealing with just the SQL Server relational engine and sometimes I would still rather be lucky than good!! 😎

Oh, another potential reason for reverting back to the original query: you hopefully have some reasonable certainty that it produces the correct results EVERY time. That may not be a true statement for the refactor - even if it is a "trivial" change. There are bugs and side-effects that present a tiny but non-zero chance of a regression.