So, I think she means, a win for everyone, and she has the right approach. But I also agree with you, the terminology isn't quite accurate.
"Conversely, there are several different conditions that constitute “losing.” The team can lose if you make a teammate feel like their contributions aren’t valuable. The product itself can also lose by missing out on early critique of its features, or by missing an opportunity to have its features developed less expensively."
I also had a similar feeling, and I think it's more productive to focus on results and goals, rather than "winning" or "losing". Nobody wants to be a loser.
Further, I don't like the term battle, as it has a negative connotation, and this is exactly what you need to control or even to get rid of in a team: battle, win/lose, blood, emotions, arguments.
In general I find the article pretty superficial and somewhat biased. In a real work environment you might have the best idea ever that might lead the product/company towards success, however, in front of you there is a senior dev/team lead to convince, and he is defensive and negative (and who knows, maybe he is having a bad moment in his life). How do you "win" this "battle"? By rationally "showing the numbers"? If we were all robots, this approach would possibly work, but in a team of 5 people there are 5 animals with 1) emotions, 2) personal problems, 3) different personalities, with ambitions, etc etc.
Finding a creative equilibrium between two ideas is the key to forming the right amount of "creative abrasion", but walking away from every discussion feeling like you won or lost is not going to get you there.
If you're arguing about smaller or inconsequential things like tabs vs. spaces or other stylistic items, you need to spend some time and document guidelines, which should be enforced equally on everyone. This saves tons of time down the line, and eliminates a lot (but, of course, not all) of these problems.