I will counter that integration tests tend to have a much bigger footprint: one test covers a lot more ground and so per line of code will catch more things. B

I will counter that integration tests tend to have a much bigger footprint: one test covers a lot more ground and so per line of code will catch more things. But, the failures from integration tests are often a lot harder to read. Even half-good unit tests tend to show exactly where the error is, and make the fix cycle much shorter. It is also much harder to write exhaustive integration tests for all of the inputs that might happen. I, as a long-term qa-ish person (I usually write testing systems) see real value in having a mixture of both system, integration (multiple systems), and unit tests, as well as end-to-end manual tests. Anything big enough needs all of these.