The main use case is for subviewports - nodes which contain a scene tree but aren't rendered with the main window, instead you grab a texture from the viewport and can display that how you like, as a mesh texture or as a sprite/texture rect, input to a shader, etc (similar to render textures in unity). You can apply a World resource to the subviewport (the default is, I believe, for them to have their own worlds), and that ensures that they are treated entirely separately from the main viewport's children and will only collide with things and be lit by objects in the subviewport. But, that may not be desired - you may want to use a subviewport to render certain objects and then apply post-processing only to those objects, but otherwise treat them like objects in the main scene - in that case you can have the subviewport share the same World as the main viewport, causing objects inside and outside of the subviewport to interact.

Similarly, there are often gameplay reasons you may want to separate physics/lighting for particular objects, and maybe even have several "spaces" in which objects can interact that you want to swap out at runtime. Stealth games where shadows are important to the gameplay, or games that have an "inner" and an "outer" in terms of physics (maybe a car in the world, and then objects inside the car in their own inner world that maybe obey slightly different physics parameters, for example).