This is already true of upstream Lua implementations. It is very easy to write thin Lua binding layers to C libraries.
That is the entire point of Lua. It’s easy to call Lua from native code, and it’s easy to call native code back from Lua, so you can have call stacks that seamlessly interweave Lua and native code.
I’m very skeptical of the idea that this can unlock improvements in performance or size. We already have LuaJIT which is plenty fast, and PUC-Lua which is so small, it runs on MCUs.
2) You may like Lua as a language and want to use it for general purpose programming, not necessarily embedding into host program
I will say though that the performance aspect has to be taken with a grain of salt, "native compilation" is not a meaningful improvement if every source line translates to multiple branches or vtable lookups. From my experience plain conversion of Lua to C (assuming you faithfully follow the specification, including coroutines, metatables, etc.) produces equal or slower code with rare exceptions for numerical loops. If it wasn't all AI generated I'd maybe spend time understanding this project.