If they're going to keep developing their game for 20 years, and they're smart, then they'll migrate sooner or later; otherwise the weight of finding developers willing to work in the ancient language that python 2.7 will become, and teach them that language, will drag them down, costing them more in the long term than a migration would. Just as it has for COBOL projects. It sounds like they are making efforts to pay down their technical debt; once they have decent test coverage, the move will be much less intimidating, and it sounds like their string-handling library is debt they really want to be rid of - it's just not top priority at the moment.
For projects that are being mothballed in "maintenance mode", sticking to the old tech makes sense. But for a project being actively developed, either you pay off your technical debt, or you pay interest on it forever.
Maybe that's true and maybe it's not. Unlike COBOL, Python 2 isn't inferior to its putative successor. Maybe people will eventually move anyway. Maybe they won't. Maybe they will, but not until after we are all dead.
Or maybe somebody will say bugger this for a game of soldiers, take the current Python 2, add such features from 3 as can be backported without breaking compatibility and release it as Python 4, and everyone will move to that and forget about Python 3 altogether. I don't know that will happen, of course, but I don't know it won't either. Prediction is hard, especially about the future.
I'd love to see an example of a project that has been actively developed for 20 years and has made a similar change. Linux comes to mind as a project old enough that has been kept updated regularly, but it has always been good-old C (not sure, though, maybe there has been some changes introduced)
(I'm not trying to be sarcastic, I think it will be interesting to see how they faced that kind of change)
You're right, migration may be needed at some point. But "at some point" is a very fuzzy definition, and my guess it that it will be later rather than sooner, giving the complexity of it. Paying interests of technical debt for this year, and we'll talk again next year indefinitely may well be an option if getting rid of technical debt is too costly. Sure, you'll pay more on the long term, but each year you'll face the same question: "Should I do this costly long term solution, or just keep going whit relative pain for a while?"
Except 20 year old code bases tend don't need much development.
PS: At one point I was maintaining one by myself and noticed hey, I don't actually have any open issues at all. Which compared to most software development is an odd place to be.
For projects that are being mothballed in "maintenance mode", sticking to the old tech makes sense. But for a project being actively developed, either you pay off your technical debt, or you pay interest on it forever.