Simply telling your subordinates to do something they can't see the benefit from is a recipe for disaster, which you already acknowledge, so make it fun for them. Gamification may not be easy for you to do, but can pan out to smooth out other, rougher, spots.
In a study conducted by Sharp et al. (2009), the researchers suggest the most influential factor on developers’ motivation was their ability to identify with their work. This means that most developers must find a sense of purpose in the work that they do, or their motivation to continue working will decrease.
You might also want to block out some time to show them not only how to do something, but also how it improves their code, their ability to maintain it, and how it can speed up their development process. Another answer by nvoigt talks about it, but I'll say it slightly differently: Show, don't tell.
You'll probably need to start out slow, such as 2-3 hours one day a week. Start out with something that's a complete mess, or simply over complicated and difficult to understand. Maybe it's something they all hate working on, but don't show them how to fix it yet. Just use it as an example, then have something else, something simpler, to show them how to do minor improvements to code can have major effects. Once you go through maybe 2-4 of these small improvements over a couple of weeks, bring it back around to the "monster mess" and use the same techniques you showed them previously to reduce, reuse, and generally uncomplicate the spaghetti code you first showed them.
You might even want to iterate through this approach. Teach them a couple things then use it on the "monster mess". Teach them a few more things, then use it to further improve the monster. Lather, rinse, repeat.
And don't just do it all yourself. Ask for ways people can see to improve the code. It's only partly a lecture, you need to get your people involved in the process. For correct answers or even close concepts, you an hand out mini candy bars, like Halloween candy (the good stuff, not the cheap junk). This also gives them an extra sugar boost for the brain to work better.
You may find that some of them already know what you want to use, but are under them impression they don't. I'm mostly a self-taught programmer. I've done lots of research over the years and understand all kinds of concepts, but I don't necessarily know the terms for those concepts. (I recently bombed an interview because of this.) They may also already use the concepts and think you aren't recognizing them for it. Or they are using them incorrectly and need only minor adjustments to do it correctly, instead of an overhaul of their process. There's a lot of different social or culture issues you may be running into that are the cause of the friction, rather than it being anything to do with the technology.
There's also plenty of websites that are centered around gamifying coding, even if they don't necessarily teach SOLID or the other principles you're trying to implement. You'll just need to research to find one that does. I've used CodinGame to improve my coding skills, but I don't remember specifically what principles, if any, the challenges taught. There's many challenges on the site and most are made by members, so they keep getting added to, so there might be something there you can use. Just make sure to get approval to do this on company time first. And yes, it needs to be done on company time, otherwise it becomes "homework" that likely won't be done.
Implementing peer programming can also help. Pairing up a senior and a junior to work on a task can teach both of them new things. It can also help them to overcome a hurdle in their learning. This can be the equivalent to 1-on-1 teaching, without you having to do the teaching. Also, one of the best ways to learn is to teach. If you can explain it to someone else, you understand it. And the easier you can explain it to someone else, the more likely you truly understand it and aren't just repeating what a book or article says.
Don't force it
No matter what you do while trying to get your team to do these "new" principles, make it compelling to them as a developer. Don't use a Performance Improvement Plan (PIP), like another Answer suggests. Putting people's jobs on the line is nearly a guaranteed way to get them to leave regardless if they complete the PIP. And if they stay, they won't trust you to try to implement more changes and another PIP. Just like every other part of life, ultimatums rarely work and almost never improve trust.
Explain to them how it's going to improve their work and personal lives. An exposed/unencrypted password can lead to breaches that'll leave them working around the clock to try to patch and restore anything mangled by the hack. Don't leave this up to chance or some imagined/unspecified distant time in the future, ask them how they would react if this happened during an important time in their life, like a wedding, vacation, kid's sports game, or whatever. Make it a practical example, relevant to them. Then remind them that fixing it now prevents that kind of disaster.
Explain how making things simpler reduces their mental load when making future changes. Explain how reusing the same methods can not only make the code simpler, but also makes it easier to find the code they are looking for. Explain how polymorphism can reduce lines of code and how sometimes it may not be appropriate. Yes, explain how some of the concepts you want to implement aren't always necessary or sometimes unnecessarily overcomplicate things. Also explain that most of these changes can be done iteratively as they are needed, not "just because I said so". Most of these concepts are just "rules of thumb", rather than set is stone, which is probably what they are really pushing back against.
Sure, this leave the door open to changes happening more slowly, but that's probably going to make it work better. Just like a diet, if you make too many changes too suddenly, you'll be off the diet faster than you got on it, and you'll never be able to get back on the diet.
Don't try to do too much all at once. I had a manager give my department a several hundred page book on SOLID principles and made us all read it. It was so boring, I couldn't make it even 5 pages without nodding off. This was while the manager was trying to make us change a very significant amount of how we wrote code almost overnight. Yes, we needed to make those changes, but there were so many changes that we couldn't keep up with it all. And it was all a command, with no room for questions or even explanations of what or why the changes were needed. Along with other significant changes in management attitude, this led me to find a different job after 4 years of being there.
Your people likely have gotten comfortable in their positions. That's not necessarily a bad thing, but the changes you are trying for are making them uncomfortable. Being uncomfortable is generally when people learn things, just don't make it too uncomfortable or you'll lose people. And you can lose them without them actually finding a different job. Make sure to work with them when they struggle and be understanding when they have reservations.
I'm not saying to baby or coddle them, just don't be a brick wall, where everything bounces off and they can't get any answers.