In an ideal world, devs would always have the time to test their own code. The unit and integration bits aren't the pain point, but once you reach the API or UI, people's knowledge varies widely. That's where a good QE org, either embedded or a mix of centralized and embedded, can be very helpful. In my past companies we've pushed to be champions or domain experts in test automation who's main purpose is to make testing for everyone else suck less. Sure, you will definitely take the brunt of test automation tasks, but some of those tasks should be targeted towards removing impediments for testing.

In one situation I ran into a team who was very frustrated with their automation because it was so slow. After a bit of investigation, I found out they were setting up all of their test data through database migrations, which were 10+ minutes slow. I asked why they weren't using the API to setup test data, to which they replied that none of them had experience with the API. After hacking away it in my spare time for a few weeks, I had a perfectly functional API client, and the tests were converted over time out of using the migrations.

I saw this the other day, and while it might sound cheesy, but someone said that QA to them was "quality acceleration", which actually fits fairly well. I have never worked at a company who had enough testers to go around. Keeping a smaller group of centralized testers to handle the really tough technical challenges, and a larger group of embedded testers who evangelize on testing practices was the most successful approach.

In this case, I wouldn't say you absolutely need a full quality team, but having some folks whose primary focus is testing and test automation to help skill up your dev teams sounds reasonable.