Python won’t break compatibility to make things faster because that’s not what it’s objective is. The kinds of changes in the video are perfectly reasonable things to add for a major release, but they won’t be added to Python because its main target user groups are looking more for the features that would be lost due to speed constraints than the speed itself. Speed is pretty clear to Julia’s objective, so bringing up the fact that Python doesn’t make breaking changes in the name of speed as a reason to suspect Julia won’t doesn’t make sense.
Changing all . operators to use into an anonymous function and broadcast in the name of performance is pretty huge and breaking change (which had a lot of casualties like Knet.jl). Changing all anonymous functions to be individual callable types which autospecialize in function calls is a huge and breaking change but resulted in fast anonymous functions. So of course Julia has a commitment to doing what it’s already doing.
But adding NamedTuples to allow keyword argument dispatching, giving a fast path for small unions, etc. are all upcoming and (mostly) non-breaking changes which add a lot of ways to optimize speed. Lots of other things, like macros for declaring local non-aliasing scopes, can be added to give speed in a clear and concise way without breaking code. Most of the changes that are lined up which are speed improvements (and that people ask for) actually seem to be non-breaking. So again, if you want to be push the breaking agenda, what exactly are you proposing to break and why?