> Embrace the API and add useful asserts like this one.

This kind of philosophy is going to lead to egregious API expansion, making Python harder to learn and remember.  You're suggesting that we have a nearly zero resistance to adding new assert variants.  

Please keep in mind that once something is added to the standard library, it is very painful to remove it later.  As far as I can tell, there has been zero usability testing of this method with actual users and there have been no user requests for it ever.  I don't see any analog for it in the unittest modules for other languages.

I don't like the method name at all and think we will regret this method if later an assertIsClosed() method is added for making sure objects have had a close() method called.

If recall correctly, Kent Beck himself opposed this kind of expansion of unittest modules, "Some of the implementations have gotten a little complicated for my taste."  He believed that the tool itself should be minimal so that it could be easily learned and mastered while letting "tests be expressed in ordinary source code".

> it is clearly DESIGNED to have specialized asserts for 
> many common use cases.

Actually, is wasn't at all.  When unittest was added, there were no specialized asserts (see https://docs.python.org/2.1/lib/testcase-objects.html ).  It was a translation of the successful and well respected JUnit module.  Its design goal was to provide user extendability rather than throwing in everything including the kitchen sink.

Python's unittest module was around for a very long time before the zoo of specialized asserts was added (courtesy of code donated by Google).