Measuring in isolation (like with, e.g., timeit) isn't really interesting.  Then everything is in L1 cache, branches are 100% predictable (because they take the same branch over & over for the duration of the test), and second-order effects on _other_ code are invisible.  For example, the 100% branch prediction comes at a hidden cost:  finite hardware branch-prediction tables had to kick out info about _other_ branches to make room for the branches in the code being tested.  Likewise other code is kicked out of instruction caches to make room for the new tests, and similarly for whatever data the test uses.  Those limited hardware resources are consumed by the new code whether or not it's run in the context of a micro-benchmark.

I'm not claiming the new special cases would slow code down "a lot", or even significantly, or even measurably.  That's not the point.  The point is that we avoid adding special cases unless there's _clear_ expected actual benefit, because when we multiply hundreds of code paths with "this could theoretically speed things up in some cases!" special tests, slowdowns _do_ become significant.  They all fight each other, and with expected-case code, for limited hardware acceleration gimmicks.

For a very simple example, we don't special-case integer division by 1.  `n // m`, when m=1, takes time proportional to the number of (internal) digits in `n`, despite that we _could_ simply return a pointer to `n` in constant time.

For the same reasons:  it's rare for code to divide by 1, and checking for anything isn't free (even if a micro-benchmark can't demonstrate it).  However, if someone had a way to divide by _any_ odd integer 5x faster than what we do now, _that_ may be worth the extra test.

That's why Raymond and I are looking for a reason to even suspect that special-casing container identity would pay off in _some_ plausibly realistic use case(s).