Use repository pattern in a mid-size Laravel app?

I have a mid-size project in Laravel which will act as an API service. I was inspired by an article 2 years ago to use the repository pattern with Eloquent. Specifically, move all queries to dedicated repositories, wrap model attributes with getters/setters, defined model constants, no use of magic query scopes, etc. Then I found criticism of this approach, saying that it's unnecessary with Active Record and even an overkill for most projects. J. Way himself warns about the visual debt.

I do understand that a large project would benefit from a Data Mapper like Doctrine, and a small one using plain Eloquent would be just fine. But what about a medium size project? Few things off the top of my head:

• TDD with focus on feature tests; unit tests for some classes
• Simple (->where(...)->get()) and complex queries (like multiple joins)
• Models are more than just POPOs (fillable, casts, getRouteKeyName, etc.)
• Pretty certain the app won't move to a different DB engine like Mongo

Considering these, should my controllers do

$products = $this->repository->paginate(100); // vs..

$products = Product::paginate(100); // worthwhile?

And if I use both depending on the complexity of the query, would I suffer from inconsistencies down the road? I don't see a point in rewriting find or get with findBy and getWith. I'm also skeptical about the getter/setter boilerplate in each model, as well the purpose of repository interfaces if I will only ever use Eloquent. At the same time, I am very aware how fat controllers can get as the codebase grows, and how ugly models can become with methods like getProductNamesByKeys.

Can't seem to find a golden mean between the two worlds.