It does sound like they might have gone a bit far, but as someone who works in an industrial context, a tool that maintains backwards compatibility rigorously is of enormous benefit.
The case you might have to make to upgrade the version of the tool you are using has to take into account the risks, and something that is maintaining a high level of backwards compatibility has a much lower level of risk.
Here are my preferences for tools, in order from most-preferred to least preferred: first, tools that have a rigorous deprecation process for breaking changes, distant second, tools that are incredibly conservative about breaking changes, pretty close third, tools that refuse to make breaking changes at all ever, astronomically distant last, tools that make breaking changes willy-nilly.
I generally eventually have to re-write to use a totally different tool for either of the middle two cases, because they just can't keep up. I would much rather make changes to my use of them based on deprecations than be forced to ditch them entirely.
(This is more a general statement - obviously refusing to make this datetime change isn't realistically going to push anybody away from Python.)
The case you might have to make to upgrade the version of the tool you are using has to take into account the risks, and something that is maintaining a high level of backwards compatibility has a much lower level of risk.