ZDoom

It depends on the size of the level and also the amount of dynamic content - and of course on the hardware you are using.

On a modern graphics card you can render the entire level in one go - but try to do the same with currently supported low end hardware and things look very different.
The reason why we had to split off GL 2 support last year was that one render optimization that traded less CPU work for more GPU work caused severe slowdowns on such weak hardware.

No, in 1998 hardware was not fast enough for that. Intel's hardware wasn't even good enough for that in 2010, and lowest end stuff today still isn't.

[quote="Graf Zahl"]With the current advances in graphics hardware it may well happen that the current render flow will eventually be scrapped because it'll be faster to process maps in larger chunks.[/quote]
Forgot to ask, but isnt they/it, graphics hardware, already fast enough to process levels without using of bsp and/or similar thing? Maybe not for something complex like community chest, but for default dooom/doom 2 levels.
Carmack said in 98, when released doom source, something like "on modern (as for 1998) hardware you can draw entire level, and still have fast enough rendering".

For homemade subsectors you should also also create some way to check is actor in sector subsector X, like creating zscript side blockmap or something more complex like bsp or k dimensional trees.
And this move you away from you original goal (I want use subsector to do X, not create subsector system and subsystems for system from scratch....life is pain :( )

What I think would be better is if the mod makes its own subsectors - that way if they do get removed from the engine as phantombeta alluded to, the mod continues to work afterward.

See this prior discussion, where I wanted to get subsectors (because they're a smaller unit of spatial division than sectors that was useful for a particular thing I wanted to do): https://forum.zdoom.org/viewtopic.php?f=18&t=58060

Not contradicting anything the devs have said here to be clear; the reasoning seems entirely sound.

Precisely that. Subsectors are an internal implementation detail, exposing that would lock the engine to its current render method for all eternity.
With the current advances in graphics hardware it may well happen that the current render flow will eventually be scrapped because it'll be faster to process maps in larger chunks.

[quote="Rachael"]No, why do you need subsector access? Why can't you just use a regular sector?

This keeps coming up and I really have to wonder why anyone needs to access subsectors at all. It's a completely render-side function and it has nothing to do with anything outside of that. Even internally, actors use sector and line data, not subsectors, to do their stuff.[/quote]
That's... Not really entirely true. IsPointInMap uses the render nodes internally, and that's a data scope function. They would actually be rather useful for anything that needs convex polygons of the sectors.
The reason they shouldn't be exported to ZScript, however, is not due to being useful or not, it's simply because doing so would make it impossible to change the implementation if necessary. (And would also lock GZDoom into having to use subsectors, which could very well change someday)

No, why do you need subsector access? Why can't you just use a regular sector?

This keeps coming up and I really have to wonder why anyone needs to access subsectors at all. It's a completely render-side function and it has nothing to do with anything outside of that. Even internally, actors use sector and line data, not subsectors, to do their stuff.

Does there are any access to subsector from zscript? Or at least access to subsector some actor is in?
Because there are subsector field on actors on c++ side, but I see no trace that it exported to zscript.