Rather than shoehorning datetime class support into existing functions, I think a separate set of functions should be written to convert between RFC 2822 timestamps and datetime instances.  Currently, email.utils has three functions dealing with date-time specification in email messages:

formatdate(timeval=None, localtime=False, usegmt=False),
parsedate(data),
parsedate_tz(data)

To work with datetime instances, we can just provide two functions.  For lack of better names, I'll call them format_datetime and parse_datetime.  Rather than using a localtime flag in the format function, I suggest to always interpret naive datetime instances (those with tzinfo = None) as time given in UTC with no information about the local time zone. Per RFC  2822, this should be formatted with "-0000" in the timezone field.  The format_datetime() may take usegmt flag, but it may be better to handle usegmt=True case by a separate format_datetime_gmt() function.

The parse_datetime() function should use a similar convention and produce aware datetime instances unless TZ field contains "-0000".  In this case a naive datetime containing unchanged time data should be produced.

The problem of guessing the local timezone offset or converting naive datetime instance presumed to be in local time to an aware instance does not belong to the email package.  This functionality should be added to the datetime module.  See issue 9527.

There is a remaining question to which I don't have an immediate answer: How should parse_datetime() handle valid RFC 2882 date-time specifications that cannot be represented as a valid datetime.  For example, a spec with seconds=60 or timezone > 2400.