1. The reason they existed in the first place was as a convenience when there were no concrete time zone types in the standard library.

Also because the machine has two datetime you might want to work with: UTC and whatever time zone the locale thinks it’s in. And either way, you may want a naive datetime.

2. Adding the `tz` argument to `now` and `timestamp` has provided a more general solution to the problem anyway.

Yup

3. They create objects that are inconsistent with the way Python treats naive datetimes, since naive datetimes are supposed to be abstract representations of a time, and if they need to be treated as a concrete time, they are taken to be local times.

“Local” is as poorly defined, and more likely to be misinterpreted, as “naive”. Local to the machine the code is running on? Local to the user? Local to the data the user is working with?

The one advantage `datetime.utcnow()` has is that it is somewhat faster than `datetime.now(tz=timezone.utc)`

Using a naive datetime for UTC is still very useful, I’d like to keep an easy, backward compatible way to get it.

-CHB