Glad this is working now. I have faith in this level. You should finish it.

SleepwalkR and ericw are doing a great job developing TrenchBroom and keeping us all mapping after 21 years... amazing. 

BTW, how much space should be left around items and monsters for them not to stuck / to appear?

Dogs in my level glued to the walls of their kennels (64x128x64) and some items don't respawn if placed too close to the walls or to the other items, but not always. Like, for example, armor and rockets goes fine together, but rockets and nails don't and niches are apparently very item-unfriendly.

This key, I was speeking about early, finally it got right where I want it, but it's like pure luck. 

All monsters are Shambler-sized in their collisions, to the best of my knowledge.

64 width, 64 height 88 tall -- says the engine source code. 

That can't be right, this fullbright box compiled just fine and didn't drop the enemy into the void with an enemy's hitbox- listed as 32x32x64 in Trenchbroom- a single unit away from the wall. Making it touch the wall still spawns it but it ends up stuck (an error is shown in the console when using developer 1), but even one unit is enough to leave it free to turn around and run. 

It might not be right. I don't work with the qbsp tools. There may be other factors in play than just what the engine says is the monster hull, which is hull->clip_mins: -32, -32, -24 to hull->clip_maxs: 32, 32, 64. 

There are two bounding box sizes: 32x32x56 and 64x64x88. There needs to be some space around and above them for the monsters to be able to move and not produce a warning (or for items not to fall out) - they must not touch a wall or ceiling, but they can be placed right on the ground. As Spud pointed out, a space as small as 1 unit can be enough. 

Vertical, have at least 1 unit of space above the heights below. 2 is recommended. The origin(center point) can be put exactly on the floor, though for monsters it is best to put 1 or 2 units above the floor at least to avoid potential position rounding errors sticking them through the floor (should be rare in newer editors).

Horizontal have at least 2 units of space beyond the sizes below.

Items are an effective 62 units tall. Items are 32x32x56 tall and get moved 6 units up on level start so that they can be "dropped" straught down to instantly put them on the floor and also check to see if they are below the floor and thus "fell out of level".

Monsters have 2 different collision hulls regardless of the bounding box sizes shown in Hammer/Worldcraft or other which negke mentioned above. The bounding box size for monsters shown in the editor should be close. Most smaller or narrower enemies use 32x32x56 (hull1), the larger enemies such as shamblers and vores use the 64x64x88 (hull2) size.
Dogs are a little wierd in that they have same size collision as shamblers, BUT...

There is a 4th layer of collisions...the qc code can define any bounding size it wants for an enemy. The engine rounds this size to the hull closest to either of the 2 enemy sizes for all collisions except raytracing and bullets. The qc lets, for unstance, giant monsters such as the gug, vermis, or boglord, get shot more easily in a way that is believable rather than only having bullets affect it right in the center 64units. Also tiny monsters such as fish or spiders don't get hurt if you shoot the empty air above or below them even though there could be 20-30 units of collision hull above these smaller enemies, shooting the air doesn't hurt them.

That is why, even though enemies appear to fit in niches in the editor and make sense from where you can shoot them, the tiny enemies still all need 57 units of vertical space. You can cheat it visually by using func_illusionary so long as the player can't reach the niche. 

That explains a lot. 

Also note that entities with bboxes will collide with each other according to their actual size, even though when colliding with BSP entities they snap to the two fixed sizes discussed above. Useful applications of this fact are left as an exercise... 

Do I need a different gbsp light and vis for Quake II or do the ones we use for q1 work? 

I think these are the most commonly used ones:
http://home.insightbb.com/~gryndehl/q2compile/quake2.html 

First up: swear I had the screenshots folder selected but oh well. I have had a quick look through mapping help re: nonsolid brushes but not finding this issue atm.
My brushes look like this in TB2
http://www.quaketastic.com/files/spz1dm1_brush1.jpg (view from above)
If i move past the vertical line here I fall through the brush
http://www.quaketastic.com/files/spz1dm1_brush2.jpg (view from below)
I am using Ericw's latest tools. 

Not sure but you can try downgrading to a different version of the tools first just in case.