1:
Nope. It's not an easy question, but I'll try to tell my experiences. Also, it clearly shows you don't understand what's a detail and what's a structural brush
So. When you compile the "vis" stage, it's an abbreviation for visibility. That means, you'll have large, invisible cubes in your map, the so called "vis blocks". You can set the parameters of this block with a switch of q3map2, but this is not needed here.
To achieve this, q3map2 splits up the 3D space with planes, so called "vis portals". Think about these as invisible walls. The surface of these walls are made ALONG THE SURFACE OF STRUCTURAL BRUSHES. And caulk. And of course, along the walls of the vis blocks.
Are you still with me? If not, load up a map in Xonotic, and use r_drawportals 1.
Vis calculation does exactly, what it says: if you're in point A, and you look to direction B to point C, what can you see? r rather, what shall the engine see and render at the same time! Those things are not the same. You can clearly see this, if you enable:
r_showtris 1
r_showdisabledepthtest 1 (no, this is NOT a built in wallhack, this is a developer tool, intended for debugging vis problems).
Look around now. If you see only parts of the map in wire render, vis is working. If you see the wireframe of the whole effin' map, with all the entities too, you're in deep shit of vis problems my friend
Cause the more you see, the more the engine has to actually render, so the more FPS that drains.
After we understand now, what vis does, here are some rule of thumbs:
A vis portal is generated on every:
-surface of visblocks
-surface of structural brushes
-surface of HINT brushes (later explained)
-brush surfaces, textured with CAULK.
Vis is NOT blocked by:
-patches
-models
-DETAIL brushes
Now, knowing all of these... Open space maps, like your or Newtonian Nightmare are a big pain in the ass for vis. Why? Because where ever you look at, you can almost see everything, so vis doesn't really help you. What you can try to do, is to move your map, so it better fits to visblocks (you can enable showing them in radiant), or try out HINT brushes.
Brushes textured with HINT forces the compile to make vis portals, where it normally won't create any. Hint is very good at corners, it can help you a lot (hint brushes are hidden by default in radiant, as they can overlap, and create a very big mess on 2D and 3D view. Look at Leave'em behind for an example). Placing hint brushes can help you improve performance, but it's hard to do, and requires a lot practice, to do it right.
So, if you understood all of these, you'll understand now why it was a very bad idea, to make the whole map structural, as every tiny bit of brush surface will make a vis portal, and for that, the compiler will have to calculate, what can be seen from there.
For the lights, there's another stage of compile, the light stage. What it does, it calculates the light and shadow falloff of light of surfaces, or individual light entities. This is a complex calculation, and it indeed can last for a long time. But there are numerous ways to speed this up. Namely, q3map2 can compile light in different quality. If you only want a test compile, it's advised to use the lower quality ones, and only use full quality on the end product. Note howeever, that the test compiles are always dimmer, than the high quality one, and don't have pretty shadows either.
Hope I could help.