Put most concisely, it's something like "making the most common use case as easy as possible can make slightly less common use cases wrong, dangerous and hard".
It's not an out of touch academic committee making these changes out of ignorance or spite. It's people who have to support more use cases than yours. Even if yours is the most common, that doesn't mean that the rest (internationalization, binary data transfer) are distant, rare outliers, or that the frequency of non-traditionally-"simple" ascii text handling applications isn't changing.
So, what is it exactly that you're trying to do?
Or do you mean that the text in the log is UTF-8, but the log itself as a whole is not, because those control characters are mixed into it in (effectively) a different encoding? Then the log isn't a single string, and shouldn't be treated as such.
Funny, I found the exact opposite, and despite $dayjob being LCD(2, 3) and the default Python on my system being 2, I've been writing all my small scripts in 3.6.
The real crime of Python 3, is not the changes, but the compatibility break. Hundreds of thousands of engineer-hours wasted on porting, worrying about compatibility, and supporting unsupported libraries or two environments at once. In the meantime, the language does not meaningfully advance, and thousands of projects are slowed down. It's such a huge effort for a gain that is not worth it.