Because it's a waste of time and it clutters unnecessarily your test codebase. I prefer to invest my time to create better tests/code rather than creating manually test objects when I can simply do something like this:

    var authenticationService = Substitute.For<IAuthenticationService>();
    authenticationService.Authenticate("goofy").Returns(true);
    authenticationService.Authenticate("Donald duck").Returns(false);

In another test I can easily create a mock that returns true regardless of the users to go on with testing other parts of the code. In your case you need to create two concrete objects that will have a different behaviour. And what if you need a test that checks that users with some roles need to be authorized? And other members of your team need to search for an existing manual mock otherwise they may end adding some utterly useless duplicated manual mock, and in big teams you can see that it can be easily a huge mess. If you are the only person to write code it's up to you to waste your time, but in a shared codebase you need to be mindful of other people.

I'd recommend looking into TDD without mocks. This video from Mark Seemann is a good place to start:

https://www.infoq.com/presentations/mock-fsharp-tdd

I do as well ... I've used mocking frameworks, and about the only time it's useful is if you have code you don't control that includes static methods. But in those cases, there are still ways to abstract that out of the code that needs to be tested

I used to do this before I saw my colleagues tests using Rhino.Mocks. I found myself willing to write far more/better tests as it got easier to generate when using the framework than rolling my own.

To be honest I don't really like London style tests and prefer to write state based tests using hand written 'fakes', which should be easy if you design your code around interfaces.