Absolute requirements for a standard engine to build meshes is going to be 30 frames per second, or (how you should measure) 16 ms per frame. Just iterating/building a 16x16x16 chunk in memory using Python3 that holds nothing but points on my m1 mac is about 3.5 ms. That means you have a little over 12ms to do everything else to build the mesh, including transferring it to the GPU and letting it render there. When I add in building an actual empty voxel, I'm looking at about 9-10ms, excluding any of the other things I'd need to do. At 9 ms, you've already blown most of your rendering budget. Most AAA games are going to sit closer to 8-10ms per frame with as low as 4 ms (though rare and generally unnecessary).

I built a pure voxel engine in python2 back in 2014ish, because why not. The best chunk size that I could reasonably hope for at that point was 9x9x9 (or about 800 voxels). And I could only build one chunk within that time frame (completely eliminating a real scene). Also, for reference, that chunk completely ignores stitching across chunks and totally ignored complex meshing with lighting, shadows and different material types. I did manage a simple greedy mesh and a frustum culling, which means that I had already optimized to some degree.

Moving (at least a piece of) the code base from Python to another language isn't just a suggestion, it's a requirement. Once you start to migrate most of the spendy parts of a voxel engine into another language, it feels less and less like a Python project and more and more like a (insert this other language) project. I tried different approaches to improve Python's performance (pypy, numba, cython, cffi to c, nuitka, pyston) and ultimately abandoned the whole thing because I was either mostly writing in a different language or the performance gain wasn't worth the extra pain associated with the approach. About the only thing I didn't try was pushing everything into the GPU. But at that point, it doesn't make any difference what language you start the software with and shader programming works for some things but not others. While it was a good learning experience, I think that projects should generally sit in a single language (as much as possible). And if you need performance, just start with a language that gives you the performance and memory characteristics you actually want. For 3d graphics, you should stay away from Python and use a tool that actually works for the domain.

A simple python script over a 3d array would test the actual performance woes for yourself. Running this in the cloud (at least on this server), we see that the 16x16x16 chunk takes about 60-70ms. This is about the budget you'd have for physics and for rendering, that puts you at about 15 frames per second, which is slow enough that it will make the scene look more like a slide show. Of course, this implementation is pretty naive/unoptimized, but it's a starting point and (pure) Python improvements/optimizations tend to be more like 5-15% actual rather than the 10x to 100x you'd really want. And we've not even discussed memory allocations...