> Right now, there is no benefit for CPython.

Please don't this until we have a clear demonstrable benefit.  As it stands now, this is all cost and no benefit.

Adding unnecessary abstraction layers just makes it more difficult for people to learn to be core devs.  Also, it will likely result in a lot of pointless code churn where each change carries a risk of a new bug being introduced.

The notion of pointer comparison is so fundamental to C code that it is counter productive to try to abstract it away.  It isn't much different than saying that every instance of "a + b" should be abstracted to "add(a, b)" and every "a[b]" should be abstracted to "index_lookup(a, b)" on the hope that maybe it might someday be helpful for PyPy or HPy even though they have never requested such a change.

From my own point of view, these need abstractions just make it harder to tell what code is actually doing.  Further, it will just lead to wasting everyone's time in code reviews where the reviewer insists on the applying the new inline function and there is confusion about whether two pointers are generic pointers or python object pointers, each with their own comparison technique.

Also, there is too much faith in functions marked as "inline" always being inlined. Compilers get to make their own choices and under some circumstances will not inline, especially for cross module calls.  This risks taking code that is currently obviously fast and occasionally, invisibility slowing it down massively — from a step that is 1 cycle at most and is sometimes zero cost to a step that involves an actual function call, possibly needing to save and restore registers.

Lastly, the API changes aren't just for you or the standard library.  In effect, you're telling the entire ecosystem of C extensions that they are doing it wrong.  Almost certainly, some will follow this path and some won't, further fracturing the ecosystem.