>What is the goal of consistency?

i don't know anything about linters or rubocop, but i do think you are wrong on this narrow point.

consistency is good in and of itself, it is not merely a symptom of your true goal of maintainability or readability as you mention in op.

id prefer someone/something that is consistently wrong to someone/something that is more often right, but randomly wrong. consistency implies methodology that can be changed and adapted, as opposes to simple mistakes that have to be assiduously monitored for.

you can train a person into a different habit and refactoring is much easier than bug hunting.

> consistency is good in and of itself

It can't be, because consistency is only a concept with no intrinsic value. The value is based on the relationship between the concept and the application.

You can say "consistency in code is good" or "consistency in code is bad", but then you've made an argument and you need back that up with reason.

> id prefer someone/something that is consistently wrong to someone/something that is more often right, but randomly wrong.

Just to be clear, we're not talking about bugs here, we're talking about style where there's, sometimes subjectively, "better" or "worse" more often than "right" or "wrong".

> consistency implies methodology that can be changed and adapted, as opposes to simple mistakes that have to be assiduously monitored for.

Consistency doesn't imply anything of the sort, but if you want to apply consistency to a problem with the goal of being able to change every instance of something you're not really solving a problem, unless your actual goal is consistency, which I argue isn't actually a goal at all.

I feel the discussion about consistency is moot because, in my experience, linters often have a different idea about consistency than humans.

Let's say I have the following three methods:

    def foo
      if broken?
        :error
      else
        @x
      end
    end

    def bar
      if broken?
        5
      else
        @y
      end
    end

    def qux
      if broken?
        nil
      else
        @z
      end
    end

If Rubocop forces me to reformat the last method as a one-liner because nil is returned implicitly, is this really more consistent (because it follows Rubocop's predictable rules)? Or is it less consistent (because these functions lose their common structure)?

The thing is, for probably a good majority of Rubocops rules, the consistency has nothing to do with correctness, it's consistency for the sake of consistency.

Whether you use ' or " for strings, or the %d shorthand or fully formed arrays in Ruby has nothing to do with the correctness of your code.

When these are trivial, it's not such a big deal - perhaps a bit of friction for developers, but not in a way that slows them down significantly. Rubocop does occasionally get into style rules that can change what your code is trying to communicate though, and those can often have negative effects.