Prefer an object over a hash, whenever the keys are significant

In general, any time you're working with a hash that has specific keys
(e.g. accessed with a literal), you've likely got an object wanting to
get out, even if it's just a struct with no other methods. The biggest
upside is more meaningful errors if you have a typo, since the default
behavior of a hash is to return nil. Cases where you don't care about
specific keys (e.g. using a hash to memoize a single argument method)
are fine.
> We use our guides often to resolve arguments in pull requests.

I think we agree here. Take the following example of a smell that is in the guides:

- Dev 1: We should extract something from this method because it's a Long Method
- Dev 2: No it's not
- Dev 1: *Checks guide* it's over 10 lines
- Dev 2: Oh, OK

vs what it might be like after this one's added:

- Dev 1: You should replace that Hash with a Struct because Primitive Obsession
- Dev 2: I think it's OK in this case
- Dev 1: *Checks guide* um, I still think you should use a Struct
- Dev 2: I just says to prefer them, and I still think it's OK in this case
- ...

My point is, in the first case, the guide does provide a way to settle the argument on when to fix a Long Method. This guide does not provide anything additional (IMO) on when to fix Primitive Obsession.