I think the issue here is that you're interpreting what I said as "everyone does everything", which is not the case. Some programmers do a lot more of one thing than another. I don't usually bother with terms like analyst, architect, etc. They're all part of the team that creates the programs, and there's a ton of overlap in responsibilities. These days I spend more time on analysis and design than on actual coding, but I still think of myself as a programmer because the end result of what my team does is still a program. You can make distinctions if you want to, but I prefer to let the process be a little more organic than that and let people contribute where they feel able to.

Much of the existing writing on managing software development argues against having the Developer themselves responsible for all the aspects you list

That's true, but there's also a counter movement in Extreme Programming and similar methods to remove some of the bulk that is caused by trying to separate these things so much. Even when these tasks are officially separated, there is a lot of collaboration required.

Exactly how would it work if each programmer in a 20 person team was responsible for defining their own time tables and deliverables?

The programming team should reach this conclusion together, with input on priorities and schedules from the business. Usually the more experienced people contribute more to this part. It requires an ability to break features up into logical chunks and a basic understanding of the system design in order to know what can be separated. I don't know any project managers who can do this without extensive hand-holding from the programming team.

A QA team should proceed as a user, not as a knowledgeable developer.

Of course, we all know this. However, there is a lot of interaction between the QA team and the programmers because not everything QA needs to know is written down. They often need to create certain conditions in order to run their tests, like artifically making a product in a store application out of stock. Doing this requires some knowledge of the data model, the interaction between the application and the database, and some basic SQL. Most business projects don't have tech specs that go into the necessary detail on this sort of thing, so help from a programmer is needed.

The bottom line is that I'm not opposed to separating these tasks, or giving out fancy titles, but the best programmers I've met knew enough about each of these things to help make them happen if the person with the official title couldn't do it for themselves.