Generally speaking, the Virtual Sequencer (and hence, virtual sequences) is intended to allow you to control (execute, or in sequencer terms "do") some number of sequencers in your testbench from a single location. One usage model is certainly reusing block level sequences, and co-ordinating them with other block level sequences to form meaningful system level tests.
Another option when using virtual sequences is to allow partioning of stimulus control. Since sequencers allow many threads to be concurrently active (and include logic to arbitrate between sequences) an environment user could constrain sequences running on the individual sequencers to generate "background traffic" or similar noise, while executing sequences of meaningful or interesting test stimulus via a virtual sequence. In this case, the config of the environment could specify the default sequence to run on a particular sequencer (background traffic) while the virtual sequence specifies the interesting sequences that are specific to the individual test.
At a high level, allowing a user the ability to write sequences that control sub-sequences on one or more sequencers (and thus, one or more interface) opens a number of doors in terms of both flexibility and reuse.