The test suite I do run is the one where I hit "run" in my IDE and then it lets be jump to what failed and debug seconds later.
That, IMO, is what mocking is about: making the tests fast and easy to run so they actually are.
We need to mock, for example, DownstreamAPI01 that our app POSTS to and GETs from, so we can put in accurate and realistic faked responses.
We don't strictly need to mock other bits of our own apps - but many people choose to do so.
Martin Fowler writes very well about this, and I hadn't even appreciated the "split" between sociable unit tests and solitary tests:
https://martinfowler.com/bliki/UnitTest.html
I can see the appeal of both sides, but (a) I prefer sociable tests as they tend to test real code more than artificial constructs, and (b) people tend to get into a mess when they try to produce pure solitary tests, leading to the "not really testing your app" example in my earlier comment.
Most unit tests should be handled at the integration level.
In 2018 I could understand the aversion to them given how unbearably slow and flaky they could be but those problems are draining away with improved tooling and faster machines.
I think before long they'll be the default - a test that is 4 seconds slower and 30% more realistic will seem like a no brainer.