The way Asp.net encourages inscrutable code through spooky action-at-a-distance dependency injection patterns is one of the things I actively dislike about working with C#. Fortunately, you can avoid most of it and be more explicit if you want, it's just not the idiomatic way. There's almost always an escape hatch to ditch the overblown abstraction layers and get down to what's actually happening.

If all else fails there's dotPeek and Reflector...

And thus killing of the ability to do proper unit testing.

If that pattern is required for proper unit-testing, I don't want to do 'proper' unit testing.

You can write code where your dependencies are injected and can be swapped out for testing without buying into a framework that makes it that difficult to reason about what code is actually being run and in what order.

I don't have experience with .NET core but taking example of Spring in Java (which gets targeted a lot for this sort of thing), you can get away with putting the logic at the outer levels without using services. However, more often then not, you end up using similar chunks of related functionality that then gets put into some common class to avoid repeating it everywhere. If you are already doing that, then why not put them in a service - its just a class with a @Service annotation that the dependency injection can take advantage of. Further, the fact that services are logical containers of such related functionality, creating them actually follows the principle of least surprise (viz. audit related stuff goes in AuditService) and testing/mocking etc becomes cleaner.

Of course, if you are writing a simple utility, then none of this is necessary - you'll probably not use Spring for it anyway and just core Java is fine.

whereby the only injection ususally is the same servuce over and over. with the occassional DatabaseMock sometimes...

Unit testing is not "sometimes" is 50% if the code you write

in your dreams maybe :-)

(not to say that this wouldnt be a good thing)