The point was that once people are looking at restructuring the code base and re-writing parts of it, it also becomes a point of evaluation other technologies and frameworks. So there is a high chance many will not switch Python 2 -> Python 3 but Python 2 -> Go or something else.
Then well ok, the answer to "What did Python 3 bring to the Python community?" becomes "Yeah it ended up driving a lot of people away", which I am sure wasn't the intended purpose of Python 3.0
The time cost of 2->3 will be less but if I know I will get better memory footprint, and faster response times I might be willing to invest some more time into it.
Or another way to look at it, once one sits down and rolls their sleeves looking to re-factor/renew/refresh the code base there is a good chance they will look around them and see what else is out there.
Or something else, yes. If the cost is potentially going to be big enough to convert for a large code base (keeping in mind testing might be a huge part of it - having to potentially re-test everything), and for very little benefit (well, unicode possibly, but it's not like Python 3's really any faster, and the GIL's still there), it makes you evaluate if it's worth enduring a bit more transition pain to convert to something else completely which would bring the possibility of new features / better speed.
It's also quite an issue for COTS software - sometimes to jump forwards and clean up APIs they have to do a huge refactor, sometime even a re-write of the API. If this is troublesome enough, it's worth taking the time to look into the competition.
Then well ok, the answer to "What did Python 3 bring to the Python community?" becomes "Yeah it ended up driving a lot of people away", which I am sure wasn't the intended purpose of Python 3.0