In my experience it has been that older developers hold on to old coding habits that are today considered dangerous and are reluctant to change that.
If you're curious about the down-votes, it may be because the above quote is an example of the particular kind of bigotry commonly referred to as "ageism". For future reference, if you are ever in a management position, that kind of thing is actionable in a work environment. You could get your backside sued off, is what I mean, if you are found to have used that in a hiring decision, for example.
What you say about the HR liability potential agrees with what I've heard from HR people, but never seen it be a factor in reality. In practice I can't imagine suing over a development gig. I can think of a million bad reasons people might not hire/let go a good developer (e.g. questions about manhole covers) but the "he's a curmudgeon who's reluctant to slap stuff together quickly" argument seems halfway legitimate.
So I say, bring it on, let's have an open discussion about who's smart, who's fast, who's wise, and when it even matters.
Wait until you deal with code by university educated engineers who follow the rules of software development to the T. Design is emergent. If you see 5 different functions doing the same thing it sounds like you should go refactor it. Private variables that are unchecked? OMG, you might want to add a few asserts and a couple tests. These problems sound insurmountable.
It sounds like you're dealing with production code that makes money, probably so much that they can afford to pay you to improve it.
I think you have the wrong adjective.