I think the point is that you don't have to keep two parallel versions of the same code, since it's possible to write a single version that it's both compatible with 2.7 and 3.X.
Exactly. A fair bit of python 3 has been backported to python 2, and there exist tools (like http://packages.python.org/six/) to help paper of the cracks. You might not necessarily be able to keep things 100% source compatible, but if you think and plan a little bit you should end up with a codebase that can quickly port over to python3 once all your third party libraries are supported and stable
I don't see any reason why I must do all this extra stuff
You don't have to do all this extra stuff. You could say I'm going with python3 and simply live without (or port or re-implement) any features from third party libraries that don't have a python2 version. Or you could say I'm going with python2 and live with the facts that the language won't be evolving any more and a few years from now most libraries will only see updates to their python3 branch. Both of those approach are also perfectly reasonable depending on the scope of the project.
When there are better alternatives available elsewhere.
Obviously if there are significantly better answers than python to the problem you're facing then you should be using one of those alternatives. I was assuming that you'd already decided that python was the best fit for an upcoming project and needed a plan on how to proceed.
In addition, if you're developing a web-based system you can write your code in preparation for Python 3. When you're ready to move over, you do a one-time port and drop Python 2.x support altogether.
Obviously this depends on a few things - deployment, time/cost etc.
