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.
> Why not add a smell if it's a principle to follow?

Personally, I don't see any value in that.

Smells by definition are things which may or may not need fixing. Any guideline we add would most likely use Avoid/Prefer to maintain the same uncertainty. If such a smell comes up in a Code Review, linking to c2 or a guideline is little difference to me; it's just knowledge duplication.

If, on the other hand, we can add some additional "original content" (more specificity, a concrete threshold, etc), then I'm all for the guideline. For example, if we wanted to incorporate the `x['y']['z']` double-access construct as a concrete no-questions-asked threshold.