I bet for every creepy message there are ten people begging to get a portion of that attention. Don't get me wrong. I'm just saying attention is badly distributed.
Given the uneven distribution of wealth being more likely then an even distribution of wealth per tick. If you now add the rule that someone having less than $100 is unhappy and someone having at least $100 is happy you end up with lower overall happiness on average compared to the initial state were erveyone has $100 and would be happy with that.
I did the same thing to help me get my head around it. For anyone else finding it difficult to imagine the probabilities in Monty Hall intuitively, consider replacing the 3 doors with 100 doors. After you choose the first door, the host opens 98 of the remaining 99 doors. That generalization, at least for me, helps to show that the problem can be reduced to the choice of 1 door vs all unchosen doors.
From the maintenance perspective I would prefer the more verbose code in most cases, because it is easier to debug. Moving the verbose code block to a method or function for reuse will fulfill the DRY principle as well. Then you can decide during debugging to step over or step into the method. Doing to much in one step would also contradict another rule: the single responsibility principle.
A counterpoint is that more declarative code can often remove the need for tedious step by step debugging because the behavior of the code is more transparent. I do most of my work in Haskell and find I don't typically need to debug it like I would for a less declarative language because the meaning of the code is much more clear.
I come from a C# background and have little experience with Haskell, so YMMV. C# got many new features over the years like LINQ or Lambda Expressions. My experience is that you get most of them if used in a moderate way. Like splitting complex LINQ into smaller parts and introduce intermediate results instead of one big query. They are also easier to test this way. Another important aspect of this topic is if you are maintaining your own code or code others have written. I used to maintain code written by another team, which only did feature development and barely any code maintenance. While doing only code maintenance on code written by others for a longer period I gained a new perspective on what's good code in the long term.
