A mock object is by definition not a real object. It implies that it’s possible that the expectations set in the mock object for a unit test do not correlate with the real object, and that means that the test may be making sure that the tested unit is malfunctioning.
This may happen with the natural evolution of code, at least with some of the mocking frameworks that don’t care to validate the mock objects with the real ones – that may be sometimes even impossible. Even if the expectations in a mock were correct in the beginning but changes are done to the real object, the existing mocks may be testing that your tested unit works with an old version of the implementation but not necessarily with the updated one.
This may mean more engineering time to figure out why things don’t work even if the unit tests passes, and more time to update all the mocks and tests that are not directly related to the area that was changed – but that had mock objects of the changed area.
One of the major reasons to use mocks is to isolate the units. And that they do well. But is absolute isolation something to thrive towards to?