It's only every 18 months. It'll probably be mosyly the same people all the time, Guido and Tim Peters could probably hold seats as long as they want them.
This was borrowed straight from Django's process; our technical board gets re-elected every release cycle.
It's a pretty low-traffic and low-turnover group in Django. I've done it four releases in a row, for example. When there's only one feature release in most years, it's not an issue at all to do a quick call for volunteers. In Django's case, often there's not a real need for an "election" since you only get as many volunteers as there are spots on the technical board.
Do you know if council members can be re-elected? Does "new council" imply a brand new set of council members? If so wouldn't that hurt institutional knowledge?
Because in any discussion about "new councils" ever, it never means that the entire council would be different. Be it a parliament, city council, a church committee, or a software project — the point isn't who is in it or for how long but rather that an election (or any other sort of opportunity for rearrangement) has been held.
"New council", in this circumstance, is shorthand for "holding an election for the council".
Well, it creates a way for other members of the core team to replace someone they disagree with without having to call for a no-confidence vote all the time. I don't know what you mean by "revolutionary", but the point of these kinds of councils is to uphold the vision and principles of the language, and so long as the people in the council are making the correct calls in those regards, there would be no reason to replace them.
One advantage of doing things this way is that it makes it easy for people to step down when they've had enough.