Opening this per @bbatsov's response to my comment on Reddit.

The meat of my argument (as copied from here):

There's a comment from Myron Marston, long time RSpec maintainer explaining this...

I've seen Marston's arguments from 2011 and mostly have never agreed. Here ~7 years later in 2018, it seems he may be starting to realize they're bad:

My rule of thumb is to use them when there's a compelling benefit,...
... but don't reach for them as the default way to write specs.

No. There's never a compelling benefit: interpreter detecting your typo and lazy loading objects under test are not compelling.

If I was concerned about an interpreter detecting a typo I'd be using a different language.

Lazy loading, what is the point? If your tests are consuming resources to the point that you need to lazy evaluate them your tests have a problem.

Remember, we're talking maintenance phase here: people need to go back to tests written months and years ago. Tracing through lazy loaded let hierarchies sprinkled with eager loaded let! with before hooks and shared examples that depend on the caller to define more lets is not maintainable.

Obscure tests is not a compelling benefit.

And really, we're talking maintainability and style, so consistency is important. Let's throwout the very important argument above and consider this. It's safe to say (I think) that after 20+ years the TMTOWTDI camp has lost out to the There should be one—and preferably only one—obvious way to do it camp. I mean that's why we're here talking style guides, right? We don't want TMTOWTDI.

In this case not everything can be done with let, you need let!. And not everything can be done with let, you need before. Why have some tests use X and some use Y and some use X and Y and maybe Z? Be consistent. KISS: use before. It's all you need.