Notice I didn't say "Negative -> Positive". It says "Junior -> Senior". Thinking about it further, I don't think it's possible to properly get to the second state (tradeoff-understanding) without going through the first (win-seeking) at some point in your career... in fact, when I'm hiring Junior devs I select for win-seeking behavior. "Tradeoff-understanding" is more of a philosophical disposition that one (IMHO the best engineers) arrives at later. "Win-seeking" is kind of related to the "I'm always right" point: A junior will say "Of course this is the best possible thing to do and there are no drawbacks" where a senior will say "Wait a sec - this might be worth doing, but let's understand what we're changing or giving up".
So, in a sense yeah - the Senior is still "looking for a win", so-to-speak but in a deeper zen-state where they realize "There are no wins: only tradeoffs".
I think the "looks for wins" attribute is just a desireable trait period (like "tries to write good code"), but the ability to weigh trade offs comes with experience and changes how one looks for wins.
In the end, you're making a smart vs. wise distinction, and the two are neither independent nor opposed.
Perhaps fixes the problem in front of them vs. thinks about the problem in context (with the context getting bigger and hairier with more experience).
I think the point is that the "easy" way is not always the right way. For example, it's easy to memoize results returned from a database for 5 minutes in response to a request for performance improvements. It's right to understand the business requirements (including performance), deployment strategy, cost of being wrong, cost of being right, and so forth.
So, in a sense yeah - the Senior is still "looking for a win", so-to-speak but in a deeper zen-state where they realize "There are no wins: only tradeoffs".