Or as a friend says, "I didn't leave programming, it left me".
The goal of most commercial development efforts is, or should be, to solve a business problem in the most permanent and cost effective way. Cost effective is a combination of the initial effort, ongoing maintenance and the cost of hardware required to run the solution.
I haven't seen many shiny *new* tools that do that any better than the *old* tools did. When you have been in this business long enough and you see the same wonderful *new* ideas come around for the third time you get a bit jaded. You realize just how pointless this wonderful new thing is. You will solve the same problem but using MUCH slower development tools and environments and in the end the product itself will be slower.
If this new skill you are hoping they will adopt is as indispensable as you seem to think it is, then lead by example! Show them how quickly you can solve the problem and how easy the new code base will be to maintain. If you can do that and they are still not interested then they are simply in the wrong business. On the other hand don't be surprised if you find out they can do the same but much quicker with their own tools and possibly produce code that runs as much as 1000 times faster. Will you be able to swallow your pride and acknowledge that you are full of BS? I doubt it.
Writing for concurrency is far from a new concept and not being able to do that is not indicative of a faded skill set. That is an essential skill set which was never acquired. Revision control systems have been around for a long time. Most systems can be learned well enough to use properly in just a few hours and they are essential to effective team work. Again not what I would call a faded skill. This is a fundamental lack. As to code reviews those cut both ways. Their pride will recover quite nicely when they review YOUR code.
Are you REALLY interested in how to make this person productive? Team your one of your "old" guys with one of the "young" guys. They will BOTH learn a lot.