This is a great comment. The language I use most is Python, and I am definitely biased toward its conventions. It's interesting to hear from the other side of the fence.
I want to suggest a slight reframing: instead of saying: "It is not all about cost-benefit," you could say "here is an addition to the 'benefits' column that hasn't been considered yet."
It's a totally reasonable argument; much better than "elegance." This was my main problem: that the critique of `unless` was much more plausible than the defence.
I agree that thinking in terms of this as additional benefits is an excellent way of thinking about this.
However, we don’t always make decisions purely on cost vs benefit. Some types of decisions, such as strategic thinking, involves unfair advantages. If cost-benefits are reasoned from a finite space in which one can find the optimal choice, unfair advantages cheats that, and operates on a potentially infinite space with imperfect information.
Not that I am saying Ruby or Python are unfair advantages :-) I’m just saying that cost-benefit is not the only way in which one can decide on something, and may not be appropriate for every situation. Being able to think in a language can potentially change how you think, and framing that as a benefit can be problematic.
I explored Ruby because I wanted to explore eloquence, semantics, and pattern languages (in the Christopher Alexander sense). I spent over ten years on it until I had my fill. Now I am exploring concurrency, reliability, uncertainty, self-healing and distributed systems — Elixir and Kubernetes. And while I still use Ruby in some tooling, it doesn’t give me the joy that Elixir does.
I want to suggest a slight reframing: instead of saying: "It is not all about cost-benefit," you could say "here is an addition to the 'benefits' column that hasn't been considered yet."
It's a totally reasonable argument; much better than "elegance." This was my main problem: that the critique of `unless` was much more plausible than the defence.