Also, I feel that a lot of people follow one style of testing very dogmatic.
Outside academic world, testing (part of software development lifecycle) depends on the type of projects, the organisational structure and the market. It it is influenced a lot by company quality definition (even if not defined properly, informal) which is highly correlated with market expectations about quality.
Of course one can choose to follow some testing principles and apply them everywhere, but I think a testing strategy should be chosen first based on project needs and then based on knowledge of the developers.
Just to give some examples:
For example if you work in web design for a consultancy it might be that you will focus on a niche so probably the projects will look similar. In this case unit tests should not be different between projects, except when the client has different quality requirements or expectations.
If you work for a product oriented company and lets say you have feature teams then probably unit tests will look similar between feature teams working on high level features but different than for the teams working on performance oriented or low level features.
If you switch companies then I think unit testing might look different as they approach software development (and so testing) and market differently, by focusing on different attributes/decisions that they think will give them leverage.
Also, in the specific case you mention (mockist vs classicist) I see a difference of the outcome of testing when applying one or the other on testing pure functions vs impure functions.
Why do you consider this distinction as being fundamental on how people approach unit testing?
And - just out of curiosity - what do you think is the difference between mockist and classicist?