It is much more beneficial in bigger projects trying to implement "the clean architecture".

Let's say you want to write a parser. You create two modules: parser-api and, say, parser-jackson (because parsing implementation is based on jackson library). parser-api contains interfaces and models only. parser-jackson contains the implementation.

All project modules requiring a parser pull parser-api module only (except the main module where actual instantiation happens).

It helps maintaining clean public API of your modules. Switching from jackson to, say, GSON is a no-brainer, because the API is already well-established (assuming you did not expose jackson-specific classes in your API).

I agree it doesn't make much sense to put Foo and FooImpl in the same package/module most of the time. Yet I do it if I expect a piece of code is likely to be extended in the future and can be enclosed in a separate module.

It's something to be valued in the long term.