Lots of old racing games used a PVS. The way it was calculated was by flying a camera around the track and calculating what was visible every few meters using occlusion culling, then at runtime you just see what section of track you're on and only draw the objects that you know are visible. Recalculating the PVS for that is definitely a slow operation!
replyPVS requires some hierarchical scene representation with no seams between walls. I know no other way to build such representation other than BSP. But BSP works fine only with pretty low-detail map geometry consisting of brushes. No large detail meshes or terrains can be used with it. If a game has a lot of open spaces or semi-open spaces it's nearly to impossible to build a BSP for it.
replyPVS does not require a hierarchical representation. You can use any representation you want. In fact the one in the article itself is not hiearchical.
replyIn practice many useful representation can be built only in a hierarchical way. Unless you want to force artist/map makers to split their maps in regions manually.
replyAll Source / Source 2 games still use both PVS (bsp/octree) and pre-baked lightmaps. Of course, they’re quite notorious for the staticness of their environments.
replyThere's nothing necessarily static about BSPs - in fact level editors use BSP brushes (other piecces of geometry stored as BSP) - exactly because calculating set operations between BSPs is fast and well defined, and results in another BSP.
replyIn fact, Red Faction, one of the first games to feature destruction on the PS2, used BSPs under the hood instead of voxels/marching cubes.
What was expensive, and made these game levels static is, was the occlusion calculation and light maps, which were relatively expensive at the time, and the fact that the first instances of those engines, like Quake were designed for the Pentium.