Nothing is more expensive than unmaintainable tests.
What I tend to want is unit tests that are cheap. Cheap to run, cheap to read, cheap to write. If they're properly simple I can rewrite them. If the requirements changed I can delete them and write new ones. If you get your testing pyramid you also know that most of your tests are cheap.
The more business logic that leaks up into your functional and integration tests, the more important it is that you are confident that the rules you have are the correct rules. Which leads into the problem space of GP.
More information is better, but more tests often give you the same information, or conflicting and therefore less information. Tests are about confidence. Can we ship this, did we break stupid things? Repeating an action for the sole purpose of soothing yourself is a form of OCD. It's not healthy.
There are a lot of things I'd love to see change in the testing world.
One would be a way to write a second implementation that is used to test or generate tests. For example if I want to test a function that adds two numbers ("add") it would be really nice to be able to write: test(add, (a, b) => a + b)
IMO tests kinda boil down to write it twice and hope you got it right once.
I routinely write a simple implementation with tests, then a fast implementation that passes the same tests, then check the two did the same thing on every call in a debug/contracts build.
Mix it with design by contact as the sibling post suggests and you get 'postcondition: did same thing as the simple implementation', which combined with tests to check said thing was broadly sensible, seems to suffice.
A lot of people are fooling themselves about the time needed to build and maintain tests vs. the benefits of having those tests.
And anyone questioning their value is seen as some lazy outsider who just doesn't get it.