Its true that interfaces can reduce coupling between, say, a given service and the consumer of that service.

That said, we now have an extremely high level of coupling between the interface and the concrete implementation of that service. That high level of coupling can make the code harder to change and refactor.

It can increase tech debt and can in fact make the code harder to understand, as following an interface method in the IDE will take you to the interface and not to the implementation.

If I could teach a developer one thing, it’s that there are no silver bullets. No patterns that must be followed each and every time. Too many developers fall into the trap of using the same tool on every problem. (The old “When the only tool you have is a hammer…” aphorism.)

So ask yourself, is this code behind this service highly likely to change in the future? Will it help to mock this particular data or service? Will I have multiple implementations of this interface? Will an interface make the code demonstrably clearer and easier to understand?

If the answer is yes, then go for it and slap an interface on it. In fact, it would be dumb not to do so.

But if all of the answers are no, then interfaces and protocols may not be the right tools for this particular job.