Note that this port of Python is almost as old as grub's Lua; we've been working on BITS since ~2009, and it has had Python support since May 2011.
For reference, the Python port consists of less than 1000 lines of code, most of which provides compatibility implementations of standard C and POSIX functions that Python expects. (Plus another couple thousand lines implementing additional C Python modules like "_smp", "_acpi", and "_efi", but those are getting smaller as we move more code into Python using ctypes.)
Your other reasons for going with Python make sense, but this one surprises me. Isn't the Python C API's reference counting tedious? I've written bindings to C libraries for both Python and Lua. With Python, I always use something higher level than the Python C API, like Cython or ctypes. With Lua, I've cranked out lots of bindings using the Lua C Api directly.
I find a single call to PyArgs_ParseTuple at the top of a Python C entry point much nicer than referencing various values off the Lua stack as they move around.
That said, we're in the process of rewriting as many of those functions as possible from C into Python itself, using ctypes.
In C, I make frequent use of "switch" statements.
Does CPython have a switch statment?
Note that Lua also does not have a switch statement: http://lua-users.org/wiki/SwitchStatement .
But let's consider Lua. Most of the Lua pogrammers I know also know C. How do they handle the so-called "impedence mismatches"? (Should this be plural? What else besides 1-based arrays?)
As far as I know Lua's target audience is, at least in part, C programmers. That's why it's made to be easy to embed in a C program.
You can't simply pull a few words out of the comment and assume it means there is no mismatch what C programmers expect and what Python offers. It doesn't mean that and wasn't meant to mean that.
You wrote "Lua's target audience is, at least in part, C programmers". That is also true of CPython. Bear in mind that these facts aren't that relevant. This code is not mean for the wider class of "C programmers". The relevant bit is "the target audience writes assembly and C". This is far different than "the target audience is assembly and C programmers", which appears to be what you think it says.
Instead, the target audience is the narrower class of people writing EFI binaries and working with the EFI protocol. As JoshTriplett further clarified, the "existing development tools in that area already support Python", but apparently not in Lua.
No problem. I get it.
The target audience for this is BIOS developers and firmware engineers. Several existing development tools in that area already support Python, including Simics and the Intel ITP, so the target audience is used to it.
Lua also has several other impedance mismatches with the target audience, such as 1-based array indexing (remember, the target audience writes assembly and C).
While people often describe Lua as "easy to embed", personally, I don't find Lua's stack-based C API easy at all; in particular, the references to stack-based indexes that change when you push or pop the stack feels like working with stack-based parameters in assembly without a base pointer, where the offset of a given location can change at any time. I much prefer the Python C API.
Finally, Lua would require additional libraries to provide a useful environment, precisely because it can assume so little about its environment. For instance, we'd need to bundle one of the Lua socket libraries in addition to Lua itself, as well as an HTTP library. Python's "batteries included" standard library works nicely here.