OK, I've pondered this some more, and in the end I think it is a reasonable proposal.
Note that there are many subtleties in various other methods already; e.g. the distinction between timetuple() and utctimetuple(), or between fromtimestamp() and utcfromtimestamp(), is not as straightforward as their names might suggest. So I think it's better not to add more utc*() functions.
If I had to do the design over I might have made a deeper distinction between aware and naive datetimes (e.g. aware being a subclass of naive) but such a redesign is not on the table.
Another (mostly unrelated) observation about datetime: even an aware datetime does not really represent an instant in time, unless its timezone has a fixed offset. For example, suppose I create a datetime representing noon, June 3rd, US/Eastern time in 2020. My best guess is that this will correspond to the instant 16:00 in UTC on that date. But I can't really tell. Maybe by then the campaign against DST has finally succeeded, and noon on that date in US/Eastern is actually 17:00 UTC. But if I store this date in a database and read it back in the year 2020, I want it to be read back as noon US/Eastern (June 3rd 2020), not as "whatever time in US/Eastern corresponding to 16:00 UTC on that date". Now you may wonder why I prefer it this way, and I'll just let you guess -- but I need this for my use case. If your use case needs to record the instant, you should use UTC or some other fixed offset zone. (And yes, I fundamentally consider pytz's behavior here a bug, and datetime's behavior a feature.)