Coding standards exist to make teams more productive. In theory, they make code easier to understand, alter, and test. In practice, they can create a dangerous amount of meta-work - teams re-write existing code over and over in pursuit of the most correct and elegant solution. Unfortunately, the meta-work problem seems worse on teams where everyone is engaged, passionate, and obsessed with doing the right thing.
As a contractor moving from project to project, I've found that excellent discipline with a rigid coding standard contributes far less to a project's success than excellent developers that are interested in results. Inconsistent coding styles are a minor nuisance to amazing developers. They're productive with or without consistency. Granted, if they encounter inconsistent code they'll ask about the current standard and stick with it. They won't, however, insist on updating every line of code in the project to the current standard. They don't insist because they've seen best practices come and go. The correct way of doing something today is not the same as the correct way of doing something tomorrow. If it was, your coding standards wouldn't evolve. So, if the correct way of doing something changes with time, maybe our definition of "correct" is broken.
That's not to say that standards don't matter. Just keep in mind that the goal of standards is productivity. If you can't guarantee re-writing to a new standard will pay for itself in the long-term, then don't waste time on it. It's far easier to justify a new standard in new or refactored code. Elegance is cool but it's not the same as results.