> Python is still under development enough to make upgrading attractive.
> If a language manages to become hugely popular and then stops development, that's how you end up with Perl or COBOL.
This contains two notions I am not sure whether they are right.
First, you argue that Python is still under development. Sure, from a language designer's view, people who use Python2 can relatively quickly learn Python3, and the language designers have interest in people migrating, so they might sell it as the same language.
But from the point of view of a language user who has a lot of legacy code and has no interest (or not even the resources) to rewrite and re-test it all, Python2 and Python3 are actually different languages. A program written in Python2 will not run with a Python3 interpreter, and there is no switch or option which would make it work. So, its different languages (which unfortunately share the same file extension for their source code files).
The second argument is somehow that organizations and people keep using Python2 "in spite of" or "although" it is not developed further. But I think many of these organizations might also chose so (perhaps not even consciously) because Python2 is stable and is not going to have breaking changes, which is identical to one of the reasons why COBOL is still used. For these users, stability is far more important than the addition of fancy new libraries, or new syntactic features which make the code actually harder to read.
Sure, there is the argument about security fixes. For web services, or software on desktops, this absolutely matters. But there are at least two domains where security fixes are far less relevant than stability and backwards compatibility: Large enterprises, and scientific research. In the first case, the code runs well shielded inside the corporate systems, and does not encounter untrusted input, so it does not matter whether it is secure. It matters more that the developer understands the code well and many edge cases are fixed. In the second case, security is, so far, a non-concern. And in addition, the people who wrote the code, which is almost always PhD students and researches which had to go for another temporary job, are no there any more in most cases, and there are no resources available to hire new people just to port the code. If new people are hired, they just will write new code, to produce new research results. Because this is what brings in the money which keeps the whole ship floating.
(There are interesting exceptions to that, some research projects are that big and long-lived, and use so much software, that they employ people who actually know both science and software engineering, but that's more the exception).
As a result, stability and backwards compatibility beats new features, and some people and organizations simply will not port because it does not meets their needs.
There is another language which is in a slow but steady process of fragmentation, C++. So far, there have no (almost no) backwards-compatible changes. But, the main selling point of C++ in the 80ies was that it was compatible to C, and now the official C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) explicitly discourage the use of C constructs like pointers (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...). At the same time, large users, such as Google, have their own C++ guidelines, which discourage C++ exceptions (https://google.github.io/styleguide/cppguide.html). The C++ Core Guidelines in turn require use of RAII which in many cases requires exceptions, especially in algorithms.
A foreseeable effect of these opposed forces is that C++ is splitting into several communities which use significantly different idioms, and it is well imaginable if some part of the different user communities gives up on backwards compatibility as well.