I agree entirely that it can be misused. I'm not sure how often it's misused versus used properly. But I don't see why I should give up a useful logic tool just because others don't know how to use it well?

Let me put it this way: Are there _any_ programming paradigms that don't get poorly used? We need to learn how to use our tools well, not reduce them to banality.

I used to work at a garage, and while an impact wrench can be the fastest way to put a tire back on a car, I eventually banned it entirely.

Everyone's lazy or overwhelmed at some point, and it made mistakes too easy to make (the problem is that it overtightens the lug nuts because the ease of use removes the proper physical feedback).

In situations where you don't have the bandwidth to perfectly educate everyone and enforce rules, sometimes it's easier to limit the toolset. A tire iron can be misused too, but it's a little harder.

On this note: I’m sad ruby style guides generally ban “and” and “or”.

   raise(“a long error string”) unless valid

This reads much worse, when the string pushes the line near max width, than:

    valid or raise(“..

Of course it’s another idiom to learn but it’s not a difficult one when used simply.

That’s a very Perl idiom, did you previously write Perl?

No, I just think for all ruby is bought into these guard clauses, it's sad that we generally reject the feature that allows putting either the condition or the consequence first, depending on which reads better.

the 2nd form implicitly returns the value of valid if it's truthy and nil if it's falsey; the 1st form always returns nil

Indeed, but the return value of a guard clause shouldn't be important!