If you wanted a mock, you needed an interface, even if there would ever only be one implementation of it in production.
You need to refactor it to use an interface just to unit test it.
Duck typing with python (e.g.) makes it easy to mock a class. One can subclass a Java class to make a mock, etc.
One can't do that in golang unless it's through an interface which then decouples tightly coupled code because [golang reasons].
I believe that's why people insert them everywhere, yes, but in the codebases I'm talking about, many (I'd say the majority, to be honest) of the interfaces aren't used for testing because they've just been cargo-culted rather than actually considered.
(Obviously this is with hindsight - they may well have been considered at the time but the end result doesn't reflect that.)
Java lends itself to over-engineering more than most languages. Especially since it seems that every project has that one committer who must be getting paid per line and creates the most complex structures for stuff that should've been a single static function.
[looks at the code bases of several recent jobs] [shakes head in violent disagreement]
If I'm having to open 6-8 different files just to follow what a HTTP handler does because it calls into an interface which calls into an interface which calls into an interface (and there's no possibility that any of these will ever have a different implementation) ... I think we're firmly into over-engineering territory.
(Anecdata, obviously)