The developer team needs someone with DBA-like skills, but they do not need a DBA because most of what the DBA does isn't of any use during the development project.
The usual problems are that the database is handed over to the DBA for "tuning" before deployment, but then it is too late. The problem is that the DBA doesn't have a clue what the tables are supposed to be used for, how they are queried, who will be using the database and when they do it. When they find something to improve on, it often turns out to require a redesign. Very costly.
Problems from the other perspective is that DBAs who aren't actively involved with the development lacks an understanding of most of the problems that needs to be dealt with during analysis or development and dismisses most issues as "it shouldn't happen with proper analysis". Which is true in a way, but too simplistic to be of any use.
Rotating people between the different functions is a great way to transfer knowledge and enhance the working methods of both teams. Adds some project knowledge to the DBA team, and adds some DBA skills to the development teams.
While I agree with much of what is written in this article, I think one-man teams are not optimal because of the lack of knowledge transfer. But I do agree with staffing teams with people like they describe.
The Spanner: The Next Generation BI Developer