In short; anything that has verifiable acceptance criteria should go through QA and they should be complete members of your sprint / agile team.
Ideally, in agile / scrum, at the end of the sprint you are able to release the completed work to production. So that work needs to be tested and verified before it can be release, which means that QA needs to be part of your estimating.
So when estimating, any work that is "testable" would have to take into account the test time and any time to resolve any found issues. This means that your velocity will likely slow down in the short term, but in the long term it will create a more stable and viable product.
- Just because a developer marks a story as done doesn't mean ALL of the acceptance criteria have been met.
- You decide to exclude QA and verify the acceptance criteria yourself. That doesn't work because the acceptance criteria is expected behavior and a QA can often make really strange things happen.
- In the unlikely event that the developer happens to do everything regarding their story perfectly; it likely has to interact with other parts of the system and that could introduce bugs.
- Not every story requires QA. For example; a documentation story or refactor story may not be something a QA needs to / can test.
That is the only instance that I can think where a QA would not be needed. Even then, they should vote on everything that is not exclusively technical.
Having said that; the above "why not" is complicated because some would say that purely technical sprints / stories are invalid because they are not delivering value. So then you go in the opposite direction and end up with massive stories that others would say are too big and need to be split into smaller stories. At that point; you have to figure out what works for the team.