There are examples of occlusion culling you could reference such as this example
Without getting into this quite complex method, you could also manually add “room” sections to your scene based on a distance from the camera origin, in itself would be simpler but still you would need to work out some sort of indexing / chunk system to find out which section would be added next based on proximity, as your geometries are essentially very lightweight they shouldnt have a disastrous impact on performance while moving around, as long as you are removing the previously indexed sections from the scene also, for longer corridors where they would fall out of proximity you could use scene.fog to create a falloff where empty sections have not yet been added.
I did take a look at your zip file, everything seems like it’s pretty well programmed, I ran the function where you’re creating the geometries through a for loop of 2000 iterations to try to emulate the problem and it simply seems you are hitting a hardware limit, without a clever use of instancing for sections that will be the same I think you will always have this problem.
Hopefully these suggestions can offer some resolve, it must be frustrating to not see the performance you hoped for in a larger scale environment but this is no fault of THREE.js in itself, the creators and maintainers of the project are quite literally masters of this realm and doing all they can to provide the most up to date rapid access to webgl.