Encourage students to learn and use advanced design
The most fundamental shift in my programing came from my attitude about details.
When I was young I wanted to pull every detail out of everything I touched, pin in down in front of me in one source file and beat it into submission. I could stand in one place and know everything.
After decades of programming my attitude is: the less I know the better. Dealing with a detail? Feh, I let other things deal with that. I already have plenty of stuff to think about right here thank you. I don't need more clutter.
I have shifted from a procedural mind set to a more abstract one.
That sounds fancy but all it means is that no mater where I am in the code, I want to think about only one problem, in only one way, from only one perspective.  Any detail that distracts from that is getting tucked away somewhere. I work very hard to make it that easy because I'm that lazy.
There are many ways to try to teach this, problems that invite students to drown themselves in details if they aren't careful. But one guiding principle has helped me see when I'm doing it right.  It has many names but the one I'm most fond of is:
Tell. Don't ask.1,2,3,4,5
If I have to ask a question then I have to deal with the answer. Usually that's a detail. The only reason I ask is because I want to do something and I don't have enough information to do it. Why can't I just tell the thing I asked to just do my something? It knows the answer, so it knows what it needs already. I should be able to just tell it &quot;do it now&quot; and it should be able to go do it without making me think about it.
Adopt this attitude and working abstractly becomes very appealing. Without it, abstraction and polymorphism are very annoying because they're getting in the way of you knowing everything. Teach your students to love not knowing.
I don't know. I don't want to know.

How to motivate students to use this?
Don't.
Motivate them to explore it. Which is better is not a settled issue. What you should teach is what problems this style addresses. How to identify situations that create a greater need for it. How to identify situations where it's irrelevant.
I've been studying every programming principle and style I could find for decades now and not one of them is something I would advise someone to adopt without critically analyzing how and whether to apply it in any given situation.
What I do recommend is practicing with them. Until you've used one while solving a real problem all your doing is being a tourist. I've watched people end their career by waving a book around preaching principles without knowing how to solve a problem.
When interviewing prospects I'd rather hear:
&quot;If you follow principle x it may help with this y issue.&quot;
than
&quot;You should always follow principle x. It's good design. Professionals always follow good design.&quot;
Spare me from fanatics that follow rules without thinking.
Encourage them to learn every principle, pattern, and practice they can. Not because they should always use them, but because when they look at code that already uses them they should understand why the code looks the way it does.
The reality is true professionals spend most of their time wading through crap code trying to get what they need out of it while causing the smallest amount of fuss they can.
The really good ones will spot some tiny little improvement they might be able to get away with while they're here. These &quot;boy scouts&quot; leave the code a little better than they found it. Give me those over the crusaders that want a complete rewrite every time they look at a new code base.
Cultivate in them a skeptical &quot;boy scout&quot; attitude. Give them all the tools but teach them to use them sparingly, wisely, and carefully.