Mocks create a false narrative when they are used to bypass actual behaviour. This can result in test code that doesn't actually follow how it's used in reality. We should aim to simplify the complexity of the code that the mocks are masking.
Although Fast feedback improves quality is a good reason for introducing mocks in the code, especially at boundaries, overly-mocked code slows down feedback because of the alternate reality. You may still end up with tests that are running quickly, but if they're no longer representative then the feedback has little utility.
Mocks which are used internally at levels of indirection, if produced without abstraction can further damage the maintainability of production and test code, which is why Indirection without abstraction is waste
Fixed by Test behaviour not implementation
Ashley Frieze, How Mocks Ruin Everything
Beyond Mock Objetcs
Indeed, Test from the outside-in produces this kind of effect, whereas focusing too much on testing everything in too small a unit of isolation can lead to overspecification and complexity, either through having too many mocks (Overmocking creates alternative facts) or focusing on the implementation (Test behaviour not implementation)
As Overmocking creates alternative facts it is possible for test cases going through many layers of indirection to run through fictitious code paths that aren't representative of the production-like behaviour.
Overmocking creates alternative facts, a heavy reliance of mocks for internal implementation details