Your explanation mostly focused on render part as much as I understand. So "building" is the hardest time.
What about working in the editor or viewport.
Well, that's a different matter. Although unused nodes don't participate in the building process, they must be handled by the Style Editor when graph is modified.
I'm not sure about the performance hit, because when user interaction is involved, it's most difficult to measure it.
If there are many unused nodes in the style editor, does it also affects performance during changing/modifying parameters or only during last build?
Unused nodes should have an impact only on stages 1,2 which are less costly. Anyway, we cannot understimate them, specially if there are tons of them.
You can test it using the Statistic window, removing unused nodes to see the difference. This is the correlation of each section with the build stages:
'Style Evaluation': stage 1
'Splines Setup' + 'Seg.Transform' + 'Geometry Setup': stage 2
'Generators': stages 3,4
'Mesh creation': stage 4
Take in account that each time you modify a parameter, or modify the style in the editor, RC triggers a rebuild event (all stages are processed).
Does this mean even things gets slow down during viewport display, they will be fine before rendering? Is it related with display settings like mesh, pointcloud etc?
Yes. 'Mesh' display mode is the most costly configuration. Segments cannot be instanced, and RC must build a whole mesh with the full geometry.
The more optimal modes for viewport are Box, Point-cloud, and Quick mesh (in this order).
One more extra question. Is randomised UVW mapping(offsetting), ruins instancing?
It depends of the render engine. V-Ray (not GPU) can apply the UVW mapping at render time and keep instancing.
This is not possible with the other engines, because we have not way to write a mapping render shader (there is not a render SDK, or this feature is not supported)