It's rather simple: you are proccessing huge grids of 3D data, it's always going to be less then-optimal unless you write parts of it in languages that can do this fast.
(This also includes interaction between blocks if you are going to processing a lot of those.)
You also will want to optimize the approach. For example, do you really need to draw each block as a cube? You could draw slabs of identical blocks as a single cuboid. That will complicate the code, but may allow you to run larger worlds faster. Also, you probably want to be smarter in computing which cubes to draw and what parts of them to draw (in a 'no reflections' world, you can see at most three faces of a cube. There is code for drawing fewer faces on lines 177-185, but that is disabled. If you figure out why, you may be able to improve the code). [My guess would be that the display does not look nice enough if you do. Maybe you will get flicker when looking at blocks near edge conditions (no pun intended)?]
Also, keeping angles in degrees means you have to convert to radians on every iteration. It is easy to get rid of that. That will be a tiny, tiny speed up, but if you want to get top speed, you will eventually have to make many of those.
Almost every such improvement in speed will come at the cost of code readability and maintainability.
Could performance be significantly improved by doing a re-write in Lua, for example? (Probably not... it's probably something in Pyglet itself...)
(FWIW, it's choppy compared to Minecraft, which is obviously much more complex and has a greater rendering distance.)