He has some points that are technically correct (the best kind of correct!), but overall this opinion is misguided.
Let's start with the part that is correct: Software engineers tend to change companies more often than those in other disciplines; it's not uncommon for a software engineer to change jobs every 2-3 years, and staying at a company for more than 5 years is rare indeed. So in that sense, he is right; you can (and possibly should; there are good reasons for doing do) change jobs after a couple years and it would not be uncommon.
If you write bad code (and let's not mince words, what he's telling you to do is to write bad code), then it is correct to say that some of the problems that arise from it will not be your problem; they will be somebody else's problem. That statement is factually accurate, as a statement.
All of this kind of misses the point, though, which is that you are working to get money (let's not kid ourselves here; the primary purpose of employment is to get money), and not working means that you don't get money, and so you need to work to maximize the amount of time you spend getting money. Which leads me into where this advice is wrong.
The core issue here is that if your code is sloppy then someone is going to realize it sooner rather than later. It's not going to take a "decade" like your coworker says; it may be more like a month or 2. Unless you're planning to leave the company in a month or 2, someone is going to find this bug (probably) and someone is going to ask questions about who did it, and they're going to realize it's you. If this happens enough, your boss may find that you are putting in too many bugs and the time it takes to fix them is worth more than your employment, and hence you find yourself without a job. That's not good. Then, once you've found yourself without a job, you'll also find yourself without a reference letter or industry connections or so on, which is going to make finding your next job harder.
The other problem with this is that, if you never think through a problem, then you never train yourself how to think through problems. This shows in interviews. You're going to walk out of this company (by being fired or otherwise), and you're going to interview for your next job, which will be a more senior role with a higher salary. Except, when you go to interview for that role, they'll ask you some senior-level problem that you'll have to solve. Except that you never thought about that because you were always lazy with your code at this company. The interviewer is not going to be impressed when you, with senior-level years of experience, come up with a buggy, shortcut-full, junior-level solution when you are interviewing for a tech lead position. So, you're going to end up taking lower level jobs forever, because you're not building up the skills you need to get higher level jobs.
So, don't do this. It's not going to work out for you. Let your coworker torpedo his own career this way if he wants, don't do it yourself.
After such a conversation, though, I may be tempted to treat pull requests from this coworker with a bit more scrutiny to make sure you don't have to deal with any crappy code of his later on.