That's a simple debate. You need all of those tests. Because they test different things.
Unit tests are fast, they can be executed on every build, maybe even before every commit.
System tests are used to test the result of the combination of units. As it requires the system to be running it takes more time. You run this maybe every hour, or once a day.
Integration tests are slow and depend on external systems. But they test things you cannot/should not do with unit tests or system test. You run these maybe daily or weekly depending on how much effort it takes reset states.
Then there's also the end-to-end test, or UI test, which sits between system- and integration-tests. This can easily be skipped if your system has no UI. But otherwise you do need it. It is also rather slow, and might even need a testing matrix to run the same tests for different clients (e.g. browsers). So you probably run this once a day, or every other day.
The less of these things you have in place, the more dangerous changing your software will be. The longer it takes to find out something broke, the longer it takes to find out why. That's why your first line of defense should be unit tests. That unit tests might touch the same code as the other test suites is irrelevant. The time to feedback is much shorter.
The above is more or less Chapter 7 and 8 of the book Continuous Delivery in a nutshell. Get the book in physical form, because if anybody challenges you, you can use it as a weapon too :)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.