When you're dealing with games that had obsolete lighting models like Fallout New Vegas had, you're also dealing with a very strict limitation on the number of lights that can be present in a set area too.
Neverwinter Nights' is actually better than FO:NV's, and I believe Kotor 2 would been built on a newer revision of the Aurora Engine.
Even as big a joke as it was in Fallout New Vegas, that iteration of Havok was capable of far more complex shapes than the cubes and cylinders I mentioned, as long as you provided the collision meshes for it.
So you're not really disproving my point here.
And to take your example; more modern engines allow you to rig up a tree (i.e. to define branches and stuff) as a standard model, and then paint weights on the branches to define how they reactive they are to wind.
Then the engine can track explosions (e.g. a source of compressive wind), other sources of wind, natural wind, etc, and naturally deform the trees this way without the animators having to animate even single a leaf.
I'm not really saying it's complex, tools can be easily made to automate this part;
But when there's overlap, i.e. lights added in one thing end up casting shadows on things added by other variables, this adds permutations that need to be catered for.
And you'll need combinations of lightmaps, waypoints, and collision data for each, which massively bloats filesize, and in the case of lightmaps, can quickly exhaust your VRAM constraints.
Unreal (at least very old versions of it) would be one of those I mentioned that'd only have cubes (and at best cylinders) available for models and entities dynamically added to the game world.
It's also one of those engines that depend on having lightmaps and proper collision data baked into the maps.
It was able to swap predefined parts of the level with others on the fly when the correct gamestate was triggered.
There are ways to avoid the problems, but it usually required you to roll your own tech that catered for your own needs, and make your own tradeoffs.
Want to dynamically spawn obstacles on the fly? keep them simple to what the engine supports for dynamic entities
Don't want to deal with complex 3D collision data and pathfinding? abstract your game as 2D with a 3D presentation and avoid it.
Don't want to deal with the storage requirements for lightmaps? base your system on dynamic lights with all their tradeoffs (no shadows, limited shading, very limited number available at any time, etc)
There's been massive strides in hardware and game engines since those times.
The quality is still below that of lightmaps, but full realtime lighting and shadows is both completely feasible and highly standard, with no weird restrictions on the number of lights or the quality of shading.
Physics engines (e.g. Havok, Bullet, ODE, etc) that are able to deal with complex shapes and collision models on the fly are widely used, so you don't need to store it in the map files
We have systems like Recast available to generate navmesh data on the fly.
We've more or less reached a point where game designers can literally just add and remove things from the world,
And all the engine systems will quickly move to accommodate it without any worry or further input required.
And without any overhead to the map files for having to store auxiliary data, except for maybe an additional entity's entry that swaps from disabled to enabled (or vice versa).
