Funnily enough for the reasons carefully explained in the article. i.e. cost vs benefit, fragility etc.
Nobody disputes that if they came for free then full unit test coverage would be a good thing. The area open to reasonable debate is whether they give the best bang per buck in terms of testing (as opposed to the role of tests in TDD - which is a different kettle of fish: http://www.drdobbs.com/tdd-is-about-design-not-testing/22921... )
You seem to be implying that I prefer all unit tests and no integration or system tests. Far from it.
A system test catches the backend API issue. A unit test can demonstrate that my component degrades gracefully if the backend API is not available (because I used a mock to provoke a timeout response).
There are plenty of systems out there that can't degrade particularly gracefully.
That said, the big issue with unit tests is they don't test the glue which is where a lot of issues happen. In languages with strong type systems, this is less of an issue.
Unit tests are great when you actually have complex logic with relevant corner cases, but when you're building web apps, 95%+ of your code is just boilerplate data munging
The problem is that it's almost always possible to achieve a similar or identical number of bugs with lower test coverage, and every test you write has a maintenance cost.
In my experience, the vast majority of test failures (after I've made a code change) end up being issues with the tests themselves, and not with the code change. If you're testing obviously-correct code, that's just more that can spuriously break later and require time and effort to fix and maintain.
I assume you are sarcastic, but cannot figure out what your actual point is. Are you disputing integration tests can find some types of errors which unit testing will not uncover?
Because they can find bugs and errors which unit tests cannot.