For example, xmlrpclib in 2.x will return either str or unicode depending on whether the particular piece of data it's returning happens to contain non-ASCII characters. In 3.x it always returns a unicode string.
I think a lot of it boils down to, sometimes you really really don't want to care about unicode. Linux filenames are one thorny issue - Linux thinks of them as strings of bytes, and a tool is broken if it can't also deal with them that way. Py3 makes it very difficult to do that correctly. There are also issues with stdin/out being opened as unicode vs byte streams.
For web development, the "unicode sandwich" (http://nedbatchelder.com/text/unipain.html) works great in my experience. However, I can see his point that for some kinds of tasks, Py3 is unambiguously a downgrade.
The problem is that in Python 3 some cases aren't easier, they've become impossible to do properly. Dealing with paths is a good example where Python 3 has created a huge mess. IO specifically stdin/-out/-err is another area in which Python 3 has created massive problems.
Regarding the huge mess, that exists with or without Python 3 if filenames use unknown, incorrect or inconsistent encodings. To treat a path as as text, e.g. to show it to a human or send to another system, you have to know its encoding. Python 3 and GTK (with its
G_FILENAME_ENCODING and G_BROKEN_FILENAMES) make this clear - some other software (like Python 2) just silently uses and propagates the broken data.
