You have to understand what BVH is.
The BVH is a Bounding Volume Hirarchy - basically a list with nodes that hold other nodes enclosing geometry.
Let’s simplify - imagine you got a cube and cut it in half. Now you cut those halfes into halfs again.
If you shoot a ray at your cube now and it hits one of the quads you created you can discard checking the stuff in the other 3 quads for ray intersection.
So caching the BVH to the disk only makes sense for static objects. If somethings not moving you don’t have to create a new BVH. e.g. a turntable animation. Only the camera, the source of the rays moves, the object stays the same, thus you can re-use the prior calculated BVH cached to the disk.
If you have lot’s of static objects and only a few moving, you use cached and dynamic BVH. It’ll not make one huge BVH over the whole scene, but for individual objects. So if you have a road, lots of trees and a moving car, only the BVH of the car will be updated when it’s moving - dynamically - the BVH of the trees and the road will be taken from the disk cache.
And if you have highly complex objects that aren’t moving you also turn on spatial splits.
So depending on your scene you choose either dynamic or static BVH, disk caching if you run dynamic BVH and most likely no spatial splits in either case.
I don’t know how cycles really works either, but that’s the general idea of acceleration structures to speed up the lookup for ray-object intersection. Else you’d have to search the whole geometry. This way you check does it hit the left or right cube? oh. the left one… drop the right one completely. does it hit the left half of the left cube or the right one? The right one? kk. drop the left part again.
Otherwise you’d had to check all triangles of the object if the ray hits it.
Blender Internal does the same thing, there it’s an octree structure.
