Consider the possibility that a company that would let the other guy become a lead simply doesn't deserve you. As a last resort, of course.

I would do nothing.

That is his code, he is responsible for maintaining it. Generally people don't use them because they don't understand them. Trying to force him to use something he is unwilling to understand is not helpful.

In your code, use the standard library, Boost libraries, and anything else that will improve your quality. When he eventually works with your code, he will be exposed to it, and perhaps embrace portions of it as he learns to understand what the libraries can do for him.

As a lead, you are in charge of those under you. If they are unwilling to use those libraries, it is your responsibility to find out why they are avoiding it, identify any compromises that should be made, and provide training, mentoring peer review, and other methods to encourage them to use the libraries in the future.

As long as he and his group are producing their deliverables on time and at spec, I wouldn't escalate it to higher. In the end, the best way to convince someone to change their programming style is to lead from the front: demonstrate that the code that you and your team produces is simpler, just as fast, more robust and takes less time to create than his style. Try to set a new standard of code quality for your organization. If he and his group can keep up, then maybe you should leave them alone. If they can't, then they'll be much more receptive to suggestions. In the end, actions speak a lot louder than words.

I would arrange for him to have a regrettable 'accident'. Despite huge advances in technology, a car's brakes may not aways work when you need them ...