Is it worth defining an interface for a service with a single implementation

In my Spring application, there's typically an interface for each service, even if there's only a single implementation, e.g.

public interface FooService {
  Foo getFoo(long id)

  Iterable<Foo> findAllFoos()

  void deleteFoo(long id)
}

@Service
@Transactional
public class FooServiceImpl implements FooService {
    // method implementations omitted
}

I think this practice originated in the olden days when mocking libraries could only generate a mock for an interface. But modern mocking libraries like Mockito can mock a class just as easily as an interface, so I'm not sure if there's any practical benefit to defining an interface for (Spring/Spring Boot) services with a single implementation?

I prefer to use an interface for @Service because we can make interface public and implementation package access. So it makes the scope tighter.

public interface FooService {

}

@Service
class FooServiceImpl implements FooService {

}

But it is for service that is used like a facade only.
Controller -> Facade Service -> other classes from Spring context

For "other classes" from Spring context that can be used by Facade Service I never use interfaces.

@Service
class FooServiceImpl {

    private final FooServiceHelper helper;

    @Autowired
    public FooServiceImpl(FooServiceHelper helper) {
        this.helper = helper;
    }

}

We can go even further and say: even we have multiple implementations, maybe better to have an abstract class or default implementation rather than an interface.

In Java applications, one good reason to create an interface that only has a single implementation is to implement Dependency inversion (D as in SOLID).

For example, in an application that has an onion / hexagonal style architecture with an infrastructure layer surrounding an application layer surrounding a model layer, you might define a PersonRepository interface in the application layer and a JdbcPersonRepository class that implements PersonRepository in the infrastructure layer. Methods of classes defined in the application layer call methods on PersonRepository to save and search for Person domain objects. JdbcPersonRepository in the infrastructure layer allows the application to save and search for Person object state in a MySQL database using JDBC.

In this design, although code execution flows down from application layer code to infrastructure layer code, code dependencies are directed up from the infrastructure layer to the application layer.

Search for explanations of onion architecture, hexagonal architecture, ports and adapters architecture and, in particular, dependency inversion.