Зачем использовать Python2 вместо Python3?

Почему некоторые продолжают использовать интерпретатор предыдущей версии, почему он еще не умер и не забыт?
Третья версия ушла далеко вперед (один async и новый GIL чего стоят), многие библиотеки были портированы (ранее, например, был повод использовать Py2 - OpenCV, но и ее портировали).
Единственный повод - поддержка старых проектов и невозможность переезда, но по-прежнему есть те, кто стартует новые проекты на Py2. Новые вопросы на StackOverflow появляются.
Зачем, какие очевидные причины?

Ответ

Очевидной причиной является несовместимость большинства старых рабочих тестированных Питон 2 программ с Питон 3.
Даже если большинство изменений тривиально (и может быть автоматизированно), переход на Питон 3 требует наличия тестов и времени программистов, трату которого надо обосновать. Питон 2 сам по себе уже хорошим языком является. Питон 3 местами лучше, но для каких-то задач может даже хуже показаться на первый взгляд.
Даже если разработчики могут найти время для перехода на новый язык, учитывая что программисты люди любознательные, Питон 3 может конкурировать с переходом и на другие языки такие как Go, OCaml (Питон 3 несовместим, но он "недостаточно несовместим" если что-то новое хочется попробовать).
Изначальной адаптации Питона 3 не помогало, то что первые версии (до Питон 3.2-3.3) не были предназначены для широкого использования. Большинство книг/ресурсов в сети использовали Питон 2 синтаксис. Обычно, предустановленная команда python запускает Питон 2 на POSIX системах.
Большинство живых популярных библиотек работают как на Питоне 2 так и 3. Существует "длинный хвост" библиотек, которые только на Питоне 2 работают (публичные и внутренние инструменты).
Из-за заявленной долгосрочной (на данный момент до 2020) официальной поддержки Питона 2, люди немного теряют оставаясь на Питоне 2 (хотя люди часто недооценивают время жизни программ).
Заставлять программистов учить разницу между текстом, представленным в виде Unicode строк и байтами создаёт заметный барьер для смены версий для нового кода. Особенно, если программист работает в окружении где текст в основном представлен в виде байт, закодированных в utf-8, или хуже: семантически текстовые интерфейсы используют исторически байтовые API на POSIX системах, которые допускают произвольные последовательности байтов (имена файлов, параметры командной строки, переменные окружения), что требует таких вещей как surrogateescape, чтобы продолжить с Unicode работать по умолчанию.
Уроки
Чтобы не повторять ошибок, можно было бы избежать смены основной версии и вводить новые изменения поэтапно (Python 4 в понимании Python 3 не должно быть):
не накапливать много несовместимых изменений, которые нужно научиться использовать и искать способ подружить со старым кодом (низкая стоимость перехода) возможно большинство новых фич убрать под from __future__ import division, print_function, unicode_literals, etc, которая включается через несколько выпусков по умолчанию (позволяет тестировать, преобразовывать код по одному модулю за раз) публиковать на PyPI модули, облегчающие переход с версии на версию, например, contextlib2, pathlib2, subprocess32, etc предоставить возможность исполнять старый код на новой версии без изменений (чтобы старые программы поддерживать—это относительно просто, если другие пункты также реализовать) конвертировать новую версию в старую, чтобы новый код в старом окружении исполнять (новые программы можно было бы на новой версии языка писать, а исполнять в старом окружении) (3to2 вместо 2to3—см. futurize и pasturize скрипты) ограничить поддержку старых версий (как сейчас 3.2, 3.3, 3.4, 3.5 поддерживаются) — только одна официальная текущая версия языка (чтобы ненужный выбор не создавать) использование semver для языка может быть вредно по психологическим причинам: вместо 3.0 можно было 2.6 выпустить с меньшим набором новых фич (изменение основной цифры может пугать без оснований) медленно убирать старые особо зловредные фичи — упомянуть в документации лучший путь, но фактически задержать на несколько лет удаление старого кода (адаптация под каждую новую версию в любом случае может требовать работы—так барьер между перехода на каждую версию не слишком высок)
В итоге:
люди, которые любят новые блестящие штучки, могут их использовать, не ожидая перехода всей кодовой базы на новую версию люди, которым надо чтоб продолжало работать, также довольны—старый код не должен ломаться (за исключением обычного ожидаемого подкручивания гаек при переходе на новую версию) особо консервативные люди продолжают сидеть на Python 2.4, 2.6 новички просто начинают с текущей единственной версии