OK, here's a VMF for you that's a little optimized. The main thing I did was add hints and func_detail things. Sometimes you just missed something that should have been func_detail or you had clearly just forgotten about it. I also removed some brushes stuck in other brushes.
I believe I have a better computer than you based on what you said your compile time was. But I don't think it will be nearly as long anymore.
Sometimes you didn't func_detail correctly though. Here's an example:
You had the selected brush set as func_detail before, when in fact it's better to square this corner off. (I also hinted across the entire face of this.) Here's all the hidden func_detail there:
Previously, you had much of that geometry cutting VVIS. There's no real reason to. You could extend the bottom brushes to the floor, I guess, but just making the whole thing func_detail is barely different in an area like this one.
Here's another area I really cleaned up:
This is the only staircase in the map I didn't completely func_detail btw, and the reason is because this is the only one where it's significant enough that it could stay. But I still made everything flush. Note also the change in wall decorations. I did that sort of trimming in many areas around the map.
Also, you frequently func_detail things that don't really need to be func_detail. For instance, in another part of the map, you have the detail of the god thing recessed into a wall:
There's no reason to func_detail that. In fact, the only brushes that need to be func_detailed are the outer bluish trim brushes. Since those are func_detail, if players render the visleafs up here, they're going to render the empty area of nodraw on the inside of this. It's not a big deal for performance probably, since it's just a small hole, but it's the principle I guess.
I also put some areaportals in near the start. You could put a func_areaportalwindow in the secret passage thing too if you wanted. Also, there's a lot of space under displacements near the hatch (above/beside spawn) that could be filled in with nodraw. It will help performance.
I did my best to clean your visleafs up. I suggest that you save your current copy as b2_old and rename mine to b2 and go back and forth, looking at the portal files, where/how I've hinted, and what things I have made func_detail. A quick way to generate a portal file (to see where the messy areas you need to clean are) is to compile with BSP only and don't run the game.
Some of your visleafs are still really complex and it's not really fixable, and they're both because of things you did when creating this map. The first is that you clearly used the 1u grid a lot. The second is that you didn't really align anything to any major grid lines. These are kind of related and lead to similar problems and frustrations.
The first thing to know is that VVIS always cuts every 1024 units, along the major grid lines: the orange and blue ones. That means that even in the following situation, where I've neatly hinted to VVIS what I want, it does some weird thing instead.
Here you can see the brush I hinted around:
Here I have it selected. 120x63x184. You have to be on the 1u scale to edit this in any dimension.
Here it is on the 8u grid.
Since you build all your stuff in weird sizes on the 1u grid, eyeball measurements, and don't have any internal consistency, stuff like this happens. VVIS cuts in weird places where you don't want it to or can't really affect it much with hinting. It's much worse in other areas of the map; I chose this spot because the effect is really easy to see.
Here's an area that suffers from the same problem, but a lot worse:
So you can see how this is a headache for VVIS and kills your compile time when you do it a lot.
The other problem with working at small grid sizes is how hard it is to do anything, how long it takes. As I was hinting this, I was constantly zooming in and out on the grid, lining things up on every side just right, zooming out to do it again or stretch a skip brush and then zoom back in to align it. It just takes forever. If you use a higher grid size during alphas, like 32 or even 64, when it comes time to detail, it's a lot easier to break into similar sized chunks. If you look at Valve maps or community maps that have gone official, the majority of the geometry is sized in multiples of 64 or just powers of 2. It's not always the case of course, but when you use those kinds of measurements everything fits cleanly on the major grid lines and is a lot easier to adjust, because you don't have to spend so much time making sure it all lines up. The second benefit of this is less leaks. You're just less likely to have 1u holes in weird corners that take forever to hunt down. The third is that you're less likely to accidentally create 1u lips that VVIS then cuts along.
This is the most I wanted to do on the main ziggurat but you can do more.
So, two things here. If your ziggurat's base and subsequent layers were powers of 2, you'd be able to cut your visleafs a lot neater in general and get by with just this big cube I threw in. But since it's a weird size randomly placed on the grid, there's a lot of unnecessary and unpreventable cuts. The second thing is that if your ziggurat's slope was consistent, you'd be able to very easily make a trapezoidal prism hint brush, but as it stands you'll have to make a different diagonal hint for each step. It'll help a lot, but the measurements make it so annoying that I don't want to do it after doing the rest. Sorry.
To be clear, I don't suggest going through and remaking everything so it fits neatly onto the grid in standard measurements. Just do it for your next map.
Anyway, be sure to check out the full scope of what I did, and if you don't understand why I did something feel free to ask me. Also let me know if something I just said is unclear or whatever.