-samplesize and _lightmapscale are two ways to do the same thing, each with its own application. I explained this already in the other thread:
You might need -samplesize for lightmap normal maps… it increases the lightmap resolution. But keep in mind that you need to be very careful about how you apply this to your map, since it increases lightmap data significantly which will certainly affect performance. I don’t usually recommend using the global (read: affect the entire map) -samplesize switch, instead it’s better to use the shader q3map_lightmapSampleSize directive to scale resolution per shader material or the func_group entity key _lightmapscale for per brush control. These gives you much better control over lightmap scaling so you can use it only on normal mapped surfaces, leaving generic surfaces at the default luxel resolution.
gridsize is something entirely different and has nothing to do with lightmaps. It controls the size of the light grid used for vertex lighting. Vertex lighting is used by the game for dynamic lighting effects on player and weapon models.
The lightgrid can be thought of as a partition of small blocks that fills the map, each containing a colour value that reflects the average colour and intensity of lighting contained within that block. As models are passed from one block to the next, the vertex colours of the model is altered by the lightgrid, creating the illusion of walking into different lighting environments. For most maps, you shouldn’t need to change this, larger terrain maps, may need this to be changed to larger units to prevent an error, something like “max grid overflow something”, I can’t remember exactly. Also used if you are noticing excessively long gridsize compile times (usually not the case since this is a fast process).
-vis -fast pretty much disables vis entirely, useful if you just want to test something quickly without having to wait for the vis stage. Not recommended for actual maps since there will be no vis optimizations at all.
If you are familiar with hints, you can think of blocksize as automatically creating portal splits axially every Nth game unit. Your mileage with this may vary depending on the map and how well you hint. Automatically generating splits is good when you aren’t that keen on hinting your map perfectly. Downside is, it doesn’t hint intuitively, it just tosses splits every Nth grid, meaning you may end up with a split right down the middle of a room, doing nothing to benefit performance.
Terrain maps may benefit from larger blocksizes, since terrain maps are usually nothing more than very large rooms. So if the average “room” size of the terrain map is 2048 units, you can change your blocksize to match. Observe how the blocksize shows up in Radiant, you may need to shift your map around to make the most of blocksize.
Really though, none of these make all that big of a difference for large maps, the default values are usually pretty versatile. Best way to optimize is to plan the layout ahead, build using the “caulk-hull” method, and smart hinting. Everything else is just fine tuning.
