Another problem is that PyUnicode_FromString() failure is not handled correctly in some cases. PyUnicode_FromString() can fail because an decoder error, but also because of a MemoryError. For example, PyDict_GetItemString() returns NULL as if the entry does not exist if PyUnicode_FromString() failed :-(
---
PyObject *
PyDict_GetItemString(PyObject *v, const char *key)
{
    PyObject *kv, *rv;
    kv = PyUnicode_FromString(key);
    if (kv == NULL) {
        PyErr_Clear();
        return NULL;
    }
    rv = PyDict_GetItem(v, kv);
    Py_DECREF(kv);
    return rv;
}
---

While working on failmalloc issues (#18048, #19437), I found some places where MemoryError caused tricky bugs because of this. Example of such issue:
---
changeset:   84684:af18829a7754
user:        Victor Stinner <victor.stinner@gmail.com>
date:        Wed Jul 17 01:22:45 2013 +0200
files:       Objects/structseq.c Python/pythonrun.c
description:
Close #18469: Replace PyDict_GetItemString() with _PyDict_GetItemId() in structseq.c

_PyDict_GetItemId() is more efficient: it only builds the Unicode string once.
Identifiers (dictionary keys) are now created at Python initialization, and if
the creation failed, Python does exit with a fatal error.

Before, PyDict_GetItemString() failure was not handled: structseq_new() could
call PyObject_GC_NewVar() with a negative size, and structseq_dealloc() could
also crash.
---

So moving from PyDict_GetItemString() to _PyDict_GetItemId() is for perfomances, but the main motivation is to handle better errors. I hope that the identifier will be initialized quickly at startup, and if its initialization failed, the failure is handled better...

There is also a _PyDict_GetItemIdWithError() function. But it is not used currently (it was in changeset 2dd046be2c88).