There are two very important ideas in this article, which I fully agree with: QA are not the only people responsible for quality - entire team is. QA act as experts and drivers of quality management process, but they should not and are not acting alone. They should have adversarial approach which is helpful on every stage of SDLC. Thus, few more items from my list why QA is useful in every engineering organization and why every team I hire has at least one QA starting from 4-5 people:

1. Quality management is a continuous process that starts with product discovery and business requirements. Developers often assume that requirements are clear and move on to building the happy path. QA often explore requirements in depth and ask a lot of good questions.

2. QA usually have the best knowledge of the product and help product managers to understand its current behavior, when new requirements suggest to change it.

3. The same applies to product design. Good designer never leaves the team with a few annotated screens, supporting developers until the product is shipped. Design QA - the verification of conformance of implementation to design specs - can be done with QA team, which can assist with automation of design-specific tests.

4. Customer support - QA people are natural partners of customer support organization, with their knowledge of the product, existing bugs and workarounds.

And just a story: on one of my previous jobs recently hired QA engineer spotted number error in an All Hands presentation. That was an immediate buy-in from founders. :)