> Removing them would make porting code from Python 2 harder
> so I think it's better to keep them for a while.

So, no deprecations.  The API is now a bit redundant but it isn't broken or problematic in any way.  We don't have to deprecate this for any reason other than to satisfy a personal sense of neatness and compactness.

This API has long history.  See  https://docs.python.org/release/1.5.2/lib/thread-objects.html.   The older the API, the more likely that there is a lot of existing code that relies on the API (including public and private projects that no longer have an active maintainer or adequate tests).

For the sake of developers who rely on the standard library being "standard" and for the mountains of existing code on PyPI, we need to have a strong aversion to unnecessary deprecations.  The deprecations cause headaches for users, they present obstacles to upgrading Python, and they increase the likelihood that package distributors will monkey-patch or duplicate the code to restore prior behavior (for example, the Hypothesis project will likely have to duplicate the code that was recently taken out of the inspect module in favor of signature objects).

Put me down for a -1 on a unnecessary deprecation.  We should put more focus on proposed new APIs and making sure that they are something we want to live with for a very long time.  The saying is that the standard library is where code goes to die and it should preferably be dead-on-arrival (one reason that Requests is not be added to the standard library is that the code is still living and evolving).