The way I look at this is one test should, ideally, find out problem. If you have a test which can fail for multiple reasons then you have to spend time figuring out which reason (or reasons) the test fail.
A unit test should be set up so that there is one reason it can fail and there is one assertion to catch that failure. When you see a failure you know exactly what failed.
There might be three reasons an integration test might fail. If you are testing the integration of code A and code B could fail because there is a bug in code A. Or there is a bug in code B. Or there could be a bug in the integration. If we set up the Continuous Integration (CI)/Continuous Delivery (CD) so that if unit tests fail, we don’t even bother running the integration tests then when an integration test between code A and code B fails, we know that all the unit tests passed. Therefore the integration test failed because code A does not integrate with code B.
Again, there were three reason the integration test might have failed but because we run unit tests first, there is really only one reason the integration test failed.
Finally, if an integration test finds ONLY the same defects as a group of unit tests, then it is a redundant test and does not need to be run. You should google “mike cohn test pyramid”. You’ll see examples of the layers of testing (unit, contract, integration, etc.). Tests on the pyramid should be pushed down to simpler tests if possible. If 5 unit tests can catch the same thing as 1 integration test then write 5 unit tests and remove the integration test. If 5 unit tests can catch 5 of 6 defects but the integration test will find the 6th defect as well, write the 5 unit tests and keep the integration test.
P.S. Testing too much is better than not enough testing, IF you are trying to reduce defects at all costs. However, too much testing might be costly and the business might decide they’d rather miss a few defects but ship for less money.