Ya, prior to now ;-) there's generally been some cost-benefit thought given to these things.  Strings and ints are immutable and some values of each are uniquely interned, so the case of identity is more than just plausible.  It happens often.

I'd guess that the bytes object inherited the identity check when old string code was edited to create the bytes type.  The case there is dubious:  as I recall, the only bytes object that's interned is the empty bytes object.

The `slice` object is a hoot.  They may never be compared outside of unit tests ;-)  The code itself is baffled by what it's doing:

"""
static PyObject *
slice_richcompare(PyObject *v, PyObject *w, int op)
{
    ...
    if (v == w) {
        /* XXX Do we really need this shortcut?
           There's a unit test for it, but is that fair? */
    ...
"""

It doesn't really care about speed:  if v != w, the code goes on to allocate two temporary 3-tuples, copy the slices' data into them, call PyObject_RichCompare() to compare the tuples, then free the temporary 3-tuples.  Slow.  Its advantage is that it's "obviously correct".

A related example:  for lists, there's an early special case for EQ and NE when the lengths of the lists differ (if lists aren't the same length, they can't be equal).  However, tuple comparison deliberately omits that special case:  while tuple comparison is quite common in some programs (e.g., lots of programs sort large lists of tuples, or index large mappings by tuples), I never found real code that compared tuples of different lengths.  So long as that's so, checking for that case is a pure waste of code, time, and HW resources.