I've not, yet, listened to the podcast so the what follows here are my initial, unfiltered, tuppence worth thoughts on the simple question regarding over-testing implied by coverage.py output so far as I understand it.
Having scanned the doc set for coverage.py, I cannot find any mechanism for determining data variance over the executed code. The outputs from coverage.py are percentages for statement and branch coverage (full or partial). There are no references regarding the input data sets triggering these lines. Without reference to the data coverage, it is not possible to determine whether any given execution of any line is unique or not, rendering that test a candidate for removal.
Care has to be exercised with the output of any process generating only coverage metric for statement/branch coverage. It may be that, in spite of a line of code being exercised multiple times, a significant boundary condition, explicit or implicit, has not been tested, resulting in a false positive. A cast error resulting in an overflow condition is just one possible example which may go undetected without data coverage analysis being carried out alongside statement/branch coverage analysis.
It may be that you're testing for something pretty esoteric, such as a memory leak, in which case re-testing the same code with the same data would be understandable. Otherwise the time given over to re-testing a line of code under identical data conditions is likely to be better spent exercising alternate data conditions.
Over-testing can also lead testing into disrepute if we claim "We've run n000 tests which have all passed." yet the application is still found to have an unacceptably high defect rate.
Coverage.py appears to represent a useful additional tool to the testers toolset, especially given the ability to drill down from the output html to the underlying .py code marked up according to whether it is covered, missing etc. As with all tools though, it's limitations have to be understood and factored in when using it and, as we all know in testing/QA, there ain't no silver bullet.