Agreed. Production DBAs are a very valuable asset who bring much needed experience to the job, and are needed in a professional organisation of any size. Development DBAs rarely cut it when it comes to sorting out the problems you addressed.
Most of the purely development DBAs I've met are more developer than DBA, ie : they are developers who know more than your average developer about databases, ie: not a lot. (apologies to those who do!)
But from personal experience, I think it's actually advantageous to follow a developer -> development DBA -> production DBA route, not least because you can talk to developers in a language they understand, and because you know the sort of shoddy tricks they get up to
I have always felt that it's a role you mature into, being a production DBA, and I don't think you can do it well unless you've got the whole picture.
Purely production DBAs tend to be oblivious to development problems, the few I've met with no development background were pretty arrogant and the developers had no time for them, which isn't a good situation.
I think part of your role as a production DBA is to educate development DBAs as to the problems seen in production, and if possibly, relay that to the development teams too.
Only by communicating the problems that you see developers causing can you educate them as to how, and why, they should do things better.
As to the future of production DBAs, I think they're always going to be around, especially with auditing requirements, but maybe with more knowledge of more recent development tools.
This is where things are changing quickly, I think you can no longer leave your development skills behind as a production DBA, but have to update them too so that you can continue to converse with the development team.
You may also see more production DBAs hiring out their services on an as-needed basis for performance tuning, or moving into information risk and security roles, working alongside the auditors, an overlap which until recently has been pretty non-existant.