You actually have two problems you are trying to solve.
They do not believe your techniques are actually better. You need a better way to demonstrate that than "I say so", and "I make more money than you do" is not actually any better.
You quoted one as saying "why would I want to do that. This works." This may have been back talk, but it also is a real question. If you cannot quantify the benefits of your approach in terms that they agree with, then you have failed in the management task of selling them on the approach. You may still have the other management stick of "do it my way", but that lacks a certain elegance, and will not result in behavioral changes.
Start from the point of view that they are your most productive employees, but that they could be more productive. Find a way to surface their current high productivity, while making it clear that it can be improved and that such improvement will have benefits. For example, if their code really is bug free but unmaintainable, try to set up some kind of metric on both factors. Do not go deep into methodology, but instead go for something as simple as "big/medium/small bug/feature", and measure output. You should find that their code produces few bugs, but that changes take substantial time compared with another approach.
Be sure everyone on the team is on board on how these will be described, and how they will be rated. For God's sake, avoid a huge meeting or an "Agile is the One True Way" pep talk. Instead, find something that everyone agrees on as a good set of metrics, that you can calculate in a short time at the start of every day, and that you can publish in aggregate on a web page. I strongly suggest that at first, individual metrics go out privately, and only aggregated group metrics go out publicly.
Train everyone, not just the senior guys, in the most effective techniques that can be applied given the environemnt. If LINQ really does make for better code, and tests really do make for fewer bugs, you should see that in your code metrics in a brief time. Being senior, you can bet that they want to improve their craft, especially if the junior guys start creating code that also does not fail. They are likely not motivated by a theoretical desire for Code Quality, but instead by a desire for a product that works. If the new techniques produce that, they will be more likely to use them.
Finally, be flexible. It may be that LINQ will not work with this team. Fine - use the techniques that will.
The deeper problem is your credibility. It sounds like you have little with them.
You are younger than they are, in a position of authority, and you are telling them that you can do their jobs better than they can. This does not make anyone feel warm fuzzies. You have also told them that if only they did it your way, they might get a big salary like yours.
Try looking at it from their perspective - they have seen people come in with the One True Way, and the code they wrote The Old Way has consistently worked better - just look at the rest of the team for proof. Further, if they are older, I bet they have worked for a young and ambitious manager who claimed that he could get them a raise, a promotion, or a big reward, only to see after much work that 'upper management would not approve it', but that the ambitious manager did get a big bonus. If you have not gotten a commitment from upper management, in writing, for a raise of, perhaps, 20%, then it is not clear you can actually offer it.
Since good managers under-promise and over-deliver, you need to carry through to build your credibility with them. Figure out the realistic improvements in measurable output that they might see in a reasonable period like three months. Then get approval from upper management for a substantial raise if they hit these targets, and propose it to them in writing. You might be surprised what they do if they are given a real offer, rather than something vague.