The C89 draft as available through a Wikipedia link, http://flash-gordon.me.uk/ansi.c.txt, specifies tm_sec range as [0, 60].  Although it looks like the range has been extended in the published version.  A discussion on comp.std.c describes the situation as follows:

"""

The "double leap second" is complete nonsense. It never existed outside the 
ANSI C standard and never will. It was introduced by the ANSI C 89 committee 
to document its problems understanding UTC issues. Someone heard that there 
are two prefered dates for leap seconds per year and this got munched up to 
the false rumour that UTC days can be up to 86402 seconds long. The 
definition of UTC, which requires that |UTC-UT1| < 0.9 s all the time, 
obviously makes double leap seconds mathematically impossible. 
"""

The latest publicly available standard that I was able to find that specifies [0, 61] range was "The Single UNIX ® Specification, Version 2" from 1997: http://pubs.opengroup.org/onlinepubs/007908799/xsh/time.h.html

Note that this range has been recognized as a mistake by Open Group:

"""
Problem:

 The valid range of seconds is no longer 0-61, a range chosen
 to accomodate the mythical double leap second.

 The correct range is 0-60 seconds.

 This has been fixed elsewhere in 1003.1-200x already.  See for
 instance <time.h>.

 Action:

 Change range to 00-60 seconds.

 Search for any other places where the range is wrongly given as 0-61
 and fix them too.
 [Ed recommendation: Accept as marked
 make the change , and add a note to the CH
 that
 The description of %S is updated so the valid range is 00-60 rather
 than 00-61.

 A search was done of the draft for other occurrences of 61 and none
 found.  ]
"""  http://www.opengroup.org/austin/docs/austin_77r1.txt

Compliance with the mistakes in old versions of various standards, does not seem like a valid goal for Python, but until a system is reported that misbehaves when tm_sec = 61 is passed to strftime, I don't see a compelling reason to change Python behavior.  On the other hand, the documentation should not refer to bogus standards, so I suggest to change 

"""
The range really is 0 to 61; according to the Posix standard this accounts for leap seconds and the (very rare) double leap seconds. The time module may produce and does accept leap seconds since it is based on the Posix standard ...
"""

to 

"""
The range really is 0 to 61; tm_sec = 60 may be necessary to represent an occasional leap second and tm_sec = 61 is supported for historical reasons.
"""