When I started unit tests way back when, half the tests were just checking what happens if you give it strange arguments.TS now does that job for me.
Another thing that has cut down on the number of tests is switching to pure functions for most things. And trying to isolate side effects as much as possible, so you really don't need to write to many tests around it. If the function only has one or two lines, typically types are enough to catch potential issues.
But C# is a typed language and generally doesn't need reams of unit tests, so all it does is make the code unnecessarily complicated.
My big bugbear was when they idiotically made the config injected, of all the things that should be super simple to use, and definitely not injected, it's config. It only changes between environments.
I think it's a false dichotomy. Where you have types, use types. Where you don't, use tests. Either way, get a tool to guide you to the answer and then check the invariant during future changes.
In fact TDD made me more aware of and appreciative of types. Writing types-by-hand is very tedious and wasteful.
Sometimes you need a test or two to really nail down this behavior. That'll give you a TDD-like flair. But it's not the same because you've already invested so much productive thinking time into the interface driven purely by the types. At that point, TDD is good hygiene, but not a transformative practice.