With immutables you simply map on players list and continue working with the copy.
Bugs avoided. Performance concerns - maybe they exist - but show me them first.
Apologies for doing a glorified +1 comment, but if you take the above comment plus the article's in-loop mutation algorithm and try it in different languages you get insights on who you are as a coder and what are the language's strengths.
Another detail is that the programmer in the article prefers an mutation iterator format while the language forces him/her to use an array/index. This has further impact on pointer vs value accesses.
Also by mapping on players list the above post means: just discard the previous one, create a new one however you want and make the new one the new source of truth. No need for mutability considerations.
I want to create it by re-using the memory of the previous one that I've just discarded, please (well, the one that will end up discarded, actually: it has to live until the map ends executing, hasn't it). Unfortunately, most of the languages' implementations/runtimes don't employ the Perceus algorithm.
If you really need it, you can always fall back to using mutables for this special list, and use immutables for the rest? This is probably the reason why languages don't implement the Perceus algorithm. If you really needed it you might as well do it by hand.
The real thing here is the definition of the Player type.
It should have a mutating method that resets it's score (a method defined on *Player).
Raw access on fields is often only ok for naive, trivial implementations. Methods are often needed anyway.
That's straightforward. Immutability doesn't make any sense here.
... Examples on how to avoid the bug ...
Notable is that you claim here is an opinion not an argument.
That immutability is not needed is also not an argument against it.
The point here is that working with immutables relieves you from some cognitive stress and repetitive work such as writing accessors and making fields private.
With mutability, it's still possible to make things immutable if properly encapsulated.
If everything is immutable by default and you need mutability for some reason, good luck.
The heuristic is simple too. If you need something to be mutable, you should deal with pointers. So *Player and []*Player here.
At the type/variable level, it's the opposite. We see it with const. Once it's in here, it's in there.