The same is often true for software. Ensuring that things integrate is vital. Ensuring that functions run in isolation also has value.
Looking at a previous project we ran full e2e tests from an end user perspective in three major browsers in less than 15 minutes at a cloud cost of only a few hundred dollars per month. Compared to the cost of developers on the project that was a negligible amount.
Adding more unit tests would make the feedback cycle shorter on some changes, but also add development time to create and maintain those tests. So in line with the article we did so only sparingly on a few critical paths that were likely to cause issues. The rest was well covered by e2e tests.
That’s not to say you can skip end to end testing, but the more testing pushed to the complete system level will drive up cost and schedule.
If I were to put a fuel injector (system under test) into a vehicle, and drive it around a parking lot (E2E test), only to have the vehicle stall out. Is the fuel injector at fault? How would you prove that?
No, you pull out the component and you "bench test" it. Believe me, after many MANY hours spend fighting bugs where the extensive E2E suite passed, we finally had to go back to adding in unit tests for the small units under the surface. Not all... but many places.