Unit tests are fast to run - but they are usually expensive to write and maintain. They are also typically full of mocks and stubs, which means the tests are tightly coupled to implementation details - which makes them high maintenance. Basically, any time something changes around a unit, the unit test needs to be updated with the mocks and stubs they interact with.
After 40 years of coding, my own testing strategy is much simpler: I use unit tests only as a stepping stone to prove the smallest units work before I build whatever is at the next layer above that unit. As soon as the next layer is in place, I write a test that covers the inner workings of the units below it - usually, that test is much simpler, and then I simply delete the complex unit tests with all of their mocks and scaffolding, and check my code coverage.
If you can get the same coverage with fewer lines of code from a higher layer, testing the same outcomes, as opposed to testing meaningless implementation details ("does it call this function", etc.) this also liberates you from the implementation details of the lower units - since these don't have unit tests binding you to these implementation details, you can now freely refactor these, without having to rewrite the complex unit tests, which means your software becomes more amenable to safe and easy architectural improvements.
Test for outcomes. Don't test for implementation details. Unit tests are just scaffolding to holds things together until the roof is on the building. Delete your unit tests as soon as it makes sense. 😊