I think that this is something that a "thought leader" said and people jumped on because for a lot of people it's certainly convenient to believe. However, if you're developing test-first, which is how you derive most of the benefits of testing, you'll need to mock. For example, if you're developing the logic to parse a single record that's returned from a service, there's no point in writing the logic to retrieve the record yet, because you couldn't check it is working because the logic to parse the record doesn't exist yet. So you pass it a fake record. That's a mock. And there are lots of different permutations it needs to handle, and it's quick and easy to change a bit here, a bit there, to exercise those edge cases. Now you need to test the logic that retrieves the record, and all you need to test is that it takes whatever you pass it through to the parsing logic, which is already tested. If you have multiple different pieces of code working together, it can be hard to even think of what data would exercise all scenarios, vs. if you isolate each piece, it's easy to imagine both the happy path and what can go wrong and provide mocks to verify each behavior.

And here are some things I've seen happen where mocking was not only not harmful, it let me keep working when everyone else was dead in the water. In one case, we needed to have a live connection to a running test environment to do "normal" development (no one but me was actually doing tests anyway), and the environment was broken because someone checked in code that broke the build. No one could run any code against the backend, but I was just fine, running my tests against mocks. We also had situations where the TypeScript build failed because of a checkin and management prioritized some other task over getting 20 developers back working. Again, my tests ran fine against my mocks, because of course the code that broke the build had no tests. We had another situation that didn't block others, but we had an edge case where no one even knew how to enter the real data into the system until after I was done coding. At other times, it was just very time-consuming to put data into a real system that would exercise the code being written.

If you're running against the real system, you could bang your head against the wall for a while, trying to figure out why you can't make your test pass--and then if finally turns out that the real code isn't producing the value you expect. And when you're testing code, the real thing you care about is, given a specific value, do you get a specific output.

Another reason to write mocks is it forces you to really know and understand what values can be provided to your code from its dependencies. Often that will involve reading the source code of someone else's library. I guarantee you you will not be a worse developer because you understand code you depend on to a greater depth than most people other than the author.