BSP Size
In order to be able to build cubemaps you have to have a copy of the map into portal2_dlc2 folder (it's a bug since Valve released the first DLC) because that folder is where the game searches into. In fact you can modify your settings in hammer in order to make it ALWAYS save a copy of your recently compiled map into that folder so you don't have to do it manually each time.
useful tools and stuff here on TWP 
[spoiler]
[/spoiler]
Nodrawing not-seen brush faces. This applies to func_details the most.
...blah blah blah...
I'm a little late, but I read somewhere that with normal brushes that are outside the map (I mean the "outer" side of the map) it doesn't matter if they are nodraw or not since hammer doesn't compile(idk if that's the right word here) them anyways.
But yeah you probably meant brushes that are inside the map but not visible. And the later tip is very important especially if you have many func_details.
That be true. This is also the case for world brushes faces which are sealed by other world brushes. Because func_details do not split leafs the engine may still render and create lighting for faces on not seen func_detail's sides.
If you ever go through Valve's maps. They usually are sloppy with the nodraw on world brushes, however very careful about where they put it on details.
Large surfaces with high-res lightmaps can eat up space pretty fast too, especially when lit by a switching or blinking light source. (Multiple lighting states = multiple lightmaps.)
The fact that your fast compile produces a bsp of half the size compared to your full compile, points in this direction, I think.
(A fast compile creates lower lightmap resolutions than a standard or full one IIRC.)
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
Just the Science Sphere was 50mb. Managed to reduce that with optimisation, reducing the lightmap of everything to 32 (its fine, most of the lighting that needs shadows is ProjTex anyway, except for the goo which is at a lightmap of 8, might up it if i can fit everything in the 100mb). Got the sphere area down to 21mb on a full compile! :3
Just turning things into func_details does not fix your visleaves. You need to use other methods such as hint+skip, visclusters for large open areas, and (for BTS and Old Aperture especially) plenty of areaportals in the right places. Also make sure your nodraw behind the displacements is placed optimally for visleaves, but hint+skip should fix most of that.
[spoiler][SP] Alternate[/spoiler]
I am reminded of something Nacimota said.
Okay a few things. Beard: What info did you get from IRC exactly? Because if someone told you that the number of visleaves would increase the filesize, they were wrong. I'm assuming you misunderstood what someone (me?) said.
Also:
Lowering lightmap scales This is the most useful; lightmaps take up a huge chunk of your BSP size
Nodrawing not-seen brush faces. This applies to func_details the most. This will have a negligible effect on file size. This only helps your in-game budget. And as was said previously, any non-detail brush face that is either facing the void or is completely covered (IE sides of brushes facing another wall) will be culled
Reducing the amount of brushes in your map This is only a partial solution; the reason it helps is because of fewer lightmap data
Using LOD model versions for distant models This has nothing to do with file size, again this just affects your in-game budget
Use cheap textures for distant textures (if available) Ditto
Use dynamic lighting (or real-time lighting) in appropriate places. Ditto
Remove unnecessary props and brushes. Ditto
Try compiling your map without VRAD and see if it still jumps up the filesize. And as others have said before, take some time to optimize your lightmaps. Anywhere that the player won't be able to access, or anywhere that doesn't need a sharp shadow being drawn on, lower the lightmap scale down.
Please do not Private Message me for assistance. Post a thread if you have questions or concerns.
If you need to contact the staff privately, contact the Global Moderators via Discord.
Hint+skip brushes and areaportals are great for optimizing framerate (when used correctly), but I've never heard of them being used to lower bsp size. Visclusters speed up compile time by telling the compiler that all the visleafs inside the cluster can see each other, but again this data must be stored in the bsp, and I don't see how it would lower the bsp size. On the other hand, maybe I'm just oversimplifying everything and these actually are factors. If so, please provide source material so that I can get educated. 
I think the biggest impacts you can have are:
1. Reduce the overall number of drawn faces in the map (Edit: this helps mostly due to removing lightmaps (#2))
2. Optimize lightmap scales (which it sounds like you are already working on)
3. Lower the quality and count of cubemaps (which you haven't added yet)
Portal 1: Portal Pro, Resurrection, Dyad, Rexaura
Portal 2: [Coop] Electrophobia, [PTI] EotM Collection, [SP] Aperture Halloween