It's like blaming America's analogue colour TV implementation (NTSC) when in fact PAL and SECAM haven't been invented yet (and NTSC is partially responsible for PAL even existing).
Honestly, Py2 was a PITA when handling raw data, it could corrupt your data if you don't know exactly what you are doing.
The goal was to separate (Unicode) text from binary data. It wasn't to UTF-16 though. In fact, you should just assume that text variables are encoded in Unicode points and not care whether it is UTF-16 or UTF-8 (and on Unix-like systems, it is definitely represented to UTF-8). If you are converting it into binary, at least you know what encoding is it: no "Oh no my Python code was broken on Windows/Unix" because even Py2 has already the UTF-16/UTF-8 OS split.
Instead they tried to split every function into a 'wide' (str) and a 'narrow' (bytes) version, like in Windows.
The whole idea of 'wide' strings is predicated on the idea that Unicode charpoints are only ever two bytes and that two bytes is all you ever need.
This obviously doesn't work in 2020, and the Python folks tried to roll back their broken by design code that has immediately turned into technical debt right out the gate, but the warts still exist. (Like having to choose whether you open files with 'w' or 'wb', etc. No other language does this stupid thing, I think.)