I would much rather write the logic the author describes in Haskell than C. The C code will have to be carefully managed during development and maintenance to make sure the side effects are happening in the expected order and that no changes ever introduce unexpected interleaving of mutation. The Haskell version will prevent that trivially. You can't even express doing it the wrong way, because you can't mutate anything.

Accidentally interleaved mutation is not a theoretical or academic problem. It's probably the number three source of production bugs in my dayjob's various products, behind misunderstood requirements and web browsers constantly changing the rules. It turns out that everyone, even people like me who know better and have been burned several times, will sometimes take the convenient shortcut. It's so tempting to get something done immediately by quietly mixing some mutation in an unexpected place, and it usually doesn't bite you. Then it gets ossified that way, and a year later starts biting you. This really does happen in code maintained by multiple developers over multiple years.

To be fair to the original post, though, Haskell has come a long way in making that kind of coding easy since 2007. The lens library didn't exist back then, and it's a big part of why data transformation programs are so much more pleasant in Haskell than most languages. It lets you express data access at the right level of abstraction. You get laws to enable algebraic reasoning and a broad range of utilities for composing small pieces together to solve complex problems.