Your examples show code snippets with different levels of clarity in it. I can communicate an idea really briefly, if you know about the domain I'm talking about. But if you don't know, I can't take shortcuts and use domain language, and will need to explain everything step-by-step.

What we see on the examples is this difference. The first one is a new programmer to Ruby (one unaware of the domain), so he uses imperative programming to explain everything step-by-step. The second example, the programmer is now aware of the domain, and can take shortcuts and use domain lingo (inject).

Simplicity in software, as in anything that is built of parts, comes from design. But clarity is all about communication. What different languages and APIs try to do is giving the programmer the vocabulary necessary to express with enough clarity the problem he needs to solve, and one that makes sense in the domain of the problem.

While these words express only relative concepts (something cannot be simple or easy on its own, but in comparison to something else), most people hear them as absolute and interpret them to mean that the work will be done quickly or cheaply.

Words like “straight-forward” more accurately express the intent almost every time.

Making your code straight-forward is a matter of making it understandable and malleable by the expected audience. You have to expect the others to have a certain skill level and write to that level, even if it is “simpler” than your own. That's how teams work.

Make things Complicated is Simplistic, make things Simple is Complex

Complex = Reduce to the most simple things as possible but not less (paraphrasing $Einstein: make things simple but not simpler).
Complicated = SmokeScreen which hides the Simplicity.

Thanks for the comment!

A pick-list of states is certainly “simpler” from the programming side but it imposes an additional cognitive burden of complexity on the user side.