I can only answer the questions as I see the answers in my case and experience. FPSC often tends to behave so widely differently across users systems and in the individual game levels they have. So these are general guidlines, brief overview or observations.
Game build time I have no concern for if there is a lot of high quality world content of any kind to accommodate during the process. - I can wait to build a game.exe it does not take very long and well worthwhile if the end result is good.
Textures I have large numbers of different textures and other content in my levels. They tend to be high quality throughout. Personally I have not noticed any significant difference at game run time using different settings nor any significant difference on impact during gameplay.
FPSC can handle large quantities of media of all kinds without any particular difficulty with the exception of characters as we know. However complexity and quality of content will add to the burden on the engine at run time as the engine struggles with all it has to do when characters or more preciseley their AI (FPSC can handle the Character models complexity fine) put the engine under stress.
The issue of the lag you refer to is well known of course but your particular reference is an interesting one as you have by your own ingenuity found the workaround for the particular causse in this instance. Well done. The workaround is documented in the past but not well known generally speaking. Some segments such as the ducts (which have flaws) you mention cause the serious lag issue to occur as you have encountered. The workaround as you have discovered is to completely enclose offending areas in further outer room segments enclosing the areas and sealing them of from leaks completely. This solution is not always ideal as one can not always do it if one can see the outer enclosing rooms so no use in outdoor areas of course. Sealing off the offending segments when effective actually reduces the number of polys the engine calculates in the build process and at run time and does not increase the number. It is the erronous segments and or build process calculations which cause FPSC to produce the massive poly count swings seen at run time which causes the serious lagg issue where it occurs in game. If suucessful then enclosing off offending areas in further segments reduces the polys and fixes the problem because FPSC does not calclate at all the polys of the outer enclosing rooms nor any unecessary splitting or mutiplication of polys (caused by the bad segments) when it divides the level up during the BSP compile process with the result that poly counts and polys to view at run time are reduced and the lag removed.
If a BSP compile process does its job well and efficiently then you can discount the number of segments you use in your levels. They will not have significant impact at run time as the engine should only draw the polys to view. FPSC can handle what you can throw at it when it does its job well, unfortunately the FPSC build process nor any other BSP engine is 100% consistent nor an exact science and FPSC does it sometimes very erratically, can see through walls and around corners and the end user has no control over it. The result can be vastly differing and erratic massive poly count swings in game view at run time as the seeing around corners and through walls serioiusly impact on the gameplay.
The two issues which cause major problems of Lagg. Characters AI routines and massive ploy count swings which cause FPSC serious lag issues both highlighted here are not user controlable. They are base engine or compile errors or inefficiencies call them what you like and beyond end user influence.
You have to live with them or work around them best you can.
Texture issues will have a relatively minor impact by comparison though in some engines size of textures used repeating over world objects do impact on poly counts during the compile process and thuse the polys to view at run time in that the process divides up world objects and spilts them into additional polys based upon the textures sizes and the nunber of reputitions. i.e. a set of polys for every repeat of the texture over a surface. I am not aware technically that FPSC does this though and viewing polys in wireframe view run time should confirm this. The FPSC tile system should ensure that you have one textures fit to one segment face and not split a segment into further polys at all.
Some entities and segments can some times generate a compile error during the build process which does not stop, when a ploy vertex or vertexes go astray and bounce around everywhere creating further polys in an endless fashion until the build process joins an offending stray vertex to a fixed point and the process ends and this results in very serious lagg at run time. If this happens and it can occasionally. I have had it happen with Default FPSC staircases cutting into walls. You can see the result in game if wireframe mode. It will sometimes cause the player to encounter invisible polys in game which you can not bypass. It will bring your game FPS to a standstill. It is a serious error and you have to remove it. Remove the entity or segment and try replacing or removing altogether and replace with another will usually fix the problem.
"There are those who said this day would never come - What have they to say Now?"