I also remember my first forays into Python 3 and the annoyance I had at some of the decisions. I recall when they relented on the % operator for string interpolation and I agree it was a poor initial choice to leave it out. I totally agree with the author that Python 3 could have made some subtle changes earlier on to help those with massive codebases.
And I still feel it was the right move. Somehow Python is even more relevant today than it was when this painful process began. While some may say that popularity is despite missteps I actually believe the general slow and cautious push forward is one of the primary reasons Python continues to succeed. There is a balance between completely abandoning old users (e.g. Perl 5 to Perl 6) and keeping every historical wart (e.g. C++). IMO, the Python community found a middle ground and made it work.
I know this because every change I've heard about is reminiscent of a Perl5 change where backwards compatibility was not broken.
The transition to Python 3 was not handled anywhere as well as it could have been.
There is a reason Go2 isn't copying Python3.
(Strangely they seem to be copying the Perl5 update model even though they don't realize it.)
The thing is that because Python has an unhealthy fixation on “There should only be one way to do things” they rejected things that would have made the transition easier. (Or even less necessary.)
I think it is kind-of telling that someone thought it necessary to create Tauthon.
Tauthon is sort-of applying the Perl5 update model to Python 2.7.
Please note that Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media).
In the original design of Perl 6, a source-level compatibility layer ("use v5") was envisioned that should allow Perl 5 source code to run inside of Perl 6. So the plan was to actually not abandon old users.
In my opinion, this failed for two reasons:
1. Most of Perl 5 actually depends on XS code, the hastily devised and not very well thought out interface to C code of Perl 5. Being able to run Perl 5 source code in Perl 6 doesn't bring you much, unless you have a complete stack free of XS. Although some people tried to achieve that (with many PurePerl initiatives), this really never materialized.
2. Then when the Inline::Perl5 module came along, allowing seamless integration of a Perl 5 interpreter inside Perl 6, using Perl 5 modules inside of Perl 6 as if they were Perl 6 modules, it basically nailed the coffin in which the "use v5" initiative found itself already in.
And now they're considered different languages after the rename to Raku, dividing already limited resources. I guess that's the way of life.