Even it is written by José I am not entirely agreeing with the gist of it.
Don’t get me wrong, The abuse of mocking is there and especially a decade and more ago mocking was a fashion, had lots of traction and was - also helped by tools - “state of the art”. That we can abuse it should not let us throw it out completely.
For my own work it helps me to write - or at least think, because documentation is not so my thing 
- what the test is actually testing. Then it will be clear that sometimes we are testing third party libraries or system libraries that should have been tested elsewhere. For example, a function that should return a timestamp and just calls a system datetime library returning the “time.now” as ticks does not need to be tested. We assume that the system library works.
For this trivial example we do not need to check the output to look for error conditions. But what alternatives do we have for more sophisticated functions? The general thinking is stubs and dependency injection. But when we
we do this, what are we testing then? tThe implementation of the injected function/module/process? Who is testing the stub?
Of course, the same applies to the mock which will be based on a mocking library, but again we hope - and sometimes in case of open source libraries we can check - that it was tested thoroughly.
So my opinion is that we should define as a community waht went wrong in the first place with mocking, what can we do to avoid it and what are the right use cases to apply it. Just saying “Forget it, it’s bad” does not help.
