> The only reason for the restriction that
> I can think of is that some text representation
> of datetime only provide 4 digits for timezone.

There never was a compelling reason.  It was simply intended to help catch programming errors for a (at the time) brand new feature, and one where no concrete timezone support was supplied at first.  Lots of people were writing their own tzinfo subclasses, and nobody at the time was, e.g., volunteering to wrap the Olson database.

I'm in favor of removing all restrictions on offsets.  Speed is of minor concern here - if it simplifies the code to delegate all offset arithmetic to classic datetime +/- timedelta operations, fine.

String representations are a mess.  If some popular standard doesn't cater to sub-minute (or sub-second!) offsets, fine, make up a format consistent with what such a standard "would have" defined had it addressed the issue, and document that if a programmer picks a timezone whose offsets go beyond what that standard supports, tough luck.  Then Python will give something sensible Python can live with, but won't try to hide that what they're doing does in fact go beyond what the standard supports.