No,"mock" here refers to some library or toolkit external to the system under test. Those mock libraries tend to require quite a bit of convoluted setup to create, involving defining both the behavior and the expectations. After the test is run, the mock runs its checks to flag any unmet expectations. The stub defined here does not include any complex setup and post-test checking. Its behavior is entirely a "no-op" version of the production dependency. In addition, because mocking tools are general purpose, they have complex logic for handling a broad range of inputs and verification tests. This technique instead uses simpler, bespoke code and leaves the Assert part of the three As to the test code.

I guess we have used different mocking libraries. The ones I'm most familiar with start with very simple use cases ("here is an object that looks like this Class, and when you call function X on it, return Y") and don't appear to have any noticeable amount of performance degradation.

One could just as easily have each class/file export a mocked object rather than a real one that happens to do nothing.

That angle of it though, I can see being beneficial. Where each class has the responsibility of defining how it should be used in a test case, vs each individual test case having to define the mocking behavior for any class it touches.

Mocks check that you call a function with the correct arguements. Stubs return a canned value but don't tell you that if they did. spys watch something happen. Fakes model the real thing with enough complexity that you write tests for them.