[lectrick]

If you work on a team and/or on a large codebase with many moving parts, unit tests on isolated parts are pretty much a necessity (by which I mean, the hands-on observed cost of not having them vs. having them, becomes so great and apparent that it is considered necessity)

Secondly, system tests won't identify the specific "faulty part". Unit tests will. That can save quite a bit of time, assuming you have enough of both types of tests.

Thirdly, unit tests inform good component design. If your unit test is hard to write, the component under test is typically either not structured well, highly coupled to other code, or some other deficiency that will result in more bugs over time, which all become readily apparent when you try to unit test it. You will end up refactoring the code under test and it will often "feel better" for lack of a better description.

Fourthly, if all you rely on is integration/acceptance/"comprehensive" tests, you will have tests that run some parts of the code hundreds of times over in a test suite run, which is incredibly wasteful. For example, a workflow integration test which requires someone to log in and try various things, will have to run the login/authentication code dozens of times, when you already know it works.