I would definitely not propose or condone sacrificing performance.

Part of the reason why I suggested the check is that it can be done efficiently - it is literally a comparison of two integers, both of which are obtained trivially. I would hope that it doesn't affect performance at all, but only measurements will show.

I looked at the implementation of threading.get_ident(), and it looks just as one would hope - a cast of pthread_self() to unsigned long, and a call to PyLong_FromUnsignedLong. If needed, it might be further improved by caching the resulting PyObject * in a __thread variable on platforms that support them, but hopefully that is not necessary. (It would require additional code to Py_CLEAR the cached PyObject * when the thread exits.) 

> I very doubt that correct asyncio program have problems like this.

That is true by definition, since what we're discussing is incorrect in asyncio. But we could be better at diagnosing the incorrect use, and we could do so (or so I hope) very efficiently. Failure to emit a diagnostic leads to bugs that are discovered much later or never.

As for why people use multi-threading with asyncio, keep in mind that many libraries create threads behind the scenes without the user being aware of it. Like me, you are a regular at python-asyncio tag, so you've seen those. In some cases you can write it off as the user doing something stupid and not reading the docs, but in many others, the mistake is far from obvious, especially for users who are not (yet) asyncio experts.