[brudgers]

One reason might be that Python 3 was not designed alongside automated migration tools. Moving a codebase from Python 2 to Python 3 comes with some of the same challenges as moving a codebase from C++ to Java: latent bugs are likely in a large code base. [1] It's worth considering that a performance critical application may call out to the Foreign Function Interface (FFI) and therefore porting from Python 2 to Python 3 involves modifying and debugging C libraries in addition to code in written in Python 2. All with 0.50 probability of below average regression test coverage in the codebase.

[1]: Without a big win comparable to managed memory.

[dith3r]

So better is to use community fork of Python 2 with new features which are not compatible with Python 2 nor Python 3. Additionally most of public libraries switched to Python 3 and Python 2 will be not supported (and probably will not be compatible with this fork). What are guarantee that this run time will fix issues, security bugs or it will not lose support after a day?

[brudgers]

Whether or not it is better in a situation depends on actual circumstances and the specific context. Better and worse alternatives are matters of engineering analysis not theory or ideology or morals.

At best, people running Python 2 do not have any good choices. Python 3 may or may not be the best among bad options. But it may not even be an option at all if the code is in production and there's not a good business case for migration.