I used to apply the Joel test religiously, but I've gradually come to the opinion that dedicated QA is a net negative. It creates a natural opposition between two halves of what should be the same team, and removes the focus that comes from knowing that what you create will be what's deployed. It also adds friction that goes against the agile "deploy early, deploy often" approach.
This is incredibly specific to one way to do QA. Arguably I'd say it's a bad way to do it, much as you can find really bad engineering practice, in which case I agree with you: bad practice is bad practice. :) People complain about how hard it is to hire good developers, and this goes double or even triple for people in the test industry, frankly.
So much depends on what the project actually needs. If developers are doing a great job of handling QA-related issues themselves, great. But sometimes you need someone to help you clear out technical debt, rig up some test infrastructure, help refine a release process, etc. And sometimes the risk of regression is so high and the product is so big that you do need an army of testers.
Likewise, for any sufficiently large project, having a dedicated person who keeps an eye on the big picture -- a clean & accurate bug DB; tracking customer reports/issues; finding & narrowing bugs -- can be an asset. This goes double when the tester's job is to be a product expert, and when the tester is reasonably technical.
And yes testers should be more or less embedded with developers. "Throw it over the wall" is invariably a terrible way to handle releases. Testers should exist to enable deploy early, deploy often, not to inhibit it. And so on. But see above re: hiring good testers. It's hard.
Anecdotally, I can say that I've seen the issue with QA causing code deployments to take far longer than they should. For example, right now we have code (one small feature) that QA wants almost two full weeks to test. I was just telling one of our QAs that I hope we start getting much better automated test coverage so that manual QA time can be brought down to a much more reasonable day or two before releasing code to the public.
Some of it comes down to incentives/culture. If QA gets yelled at when bugs go out, they're going to take a conservative approach.
It's funny, though, to hear you "hope" you start getting better automated test coverage. :) It happens pretty often that QA is the sole owner of automated tests, which has its own set of potentially bad incentives.
