I may be wrong, but I thought it was due to unresolvable DST fold issues that are mooted by PEP 495.  (At least that was the reason I did not push for LocalTimezone as hard as I did for the fixed offset class.)

I am definitely +1 on having LocalTimezone (or timezone.local) in the datetime module, but there is one reason why I would rather see it as a part of a larger Olson TZ database-size offering.

If we just add LocalTimezone, pickling a datetime instance on one system and reading it on another with a different TZ will result in changing the time value.

On the other hand, if we have a complete TZ database, then LocalTimezone can simply become an alias for Zoneinfo(os.environ['TZ']) and there will be no problem sharing aware datetime objects between systems that use the same version of the database.