I'm usually in the opposite position - when developers want to do so much refactoring that it starts to encroach on delivering business value. That being said, refactoring is a process like any other, and I have had teams fearing process change. It's about convincing the team to come with you.
The link that you have pasted tells your team why refactoring is good in general, but it would be more helpful to be more specific. For your team, why is refactoring important? Is it about a complex code base that is difficult to extend? Does it not scale? Do features take too long? Is the ramp-up time for new developers too long? Any change to a process is supposed to fix something - so be clear about what you are trying to fix. By approaching it from fixing broken things you can also validate if there are other things apart from refactoring that should be introduced.
Then when you have your team understanding what it is and why it's important, it becomes about how to actually get them to do it. First you will need to get rid of any roadblocks that stop them. That might mean allocating more time to building automated tests, or allocating more time for pair programming. Second, it's about checking that it's being done. When I introduce a coding standard change, I get one or two engineers to perform second-level code reviews across a random set of sprint work to see how many commits conform to the new standard. Then we discuss the findings in the retro so that we can talk about why the results looks a certain way.
In summary, refactoring is a process. Understand why you are implementing a new process. Help people get started. Talk about the results. Good luck :)