I don't think the whole print vs print() problem is a straw man (or similarly the division operator switch) apart from being relatively easy to fix or avoid by importing from __future__, but crucial in understanding the attitude the language owners have for its users. They could have kept print and introduced printf(), but they didn't. They didn't even get rid of the statement vs. expression distinction, which would have been a compelling reason to break print (and would give us real lambdas).

The split you mention is real, but it's existed even longer than the 2vs3 split. All the various alternate Python implementations that have come and gone or are still around with the exception of Numba were started pre-3k. I wouldn't even argue that upstream was necessarily wrong not to prioritize performance and more specific use cases (like certain production uses, or scientific uses (a lot of begging to finally get the @ operator)), it just didn't matter as much for a long time. But things are different now. There are many other very expressive and much faster (either dynamically typed or static) languages in competition that lessen Python's effectiveness at reducing dev time in exchange for more hardware. Without a more serious focus on performance, Python will be driven only by momentum. That can last a long time, and is essentially the end point anyway when performance is "good enough" compared to the close alternatives, but it's not a great look when there's still much that could be done.

So, you see, I know a bit about writing efficient code. I have held a firm belief, and still do, that if you're doing heavy lifting in CPython, you're doing it wrong, and better parallelism will not significantly help you.