Virtual pins are placed as feeding the input LUT in a free ALM, which can be placed very close to your design logic. Timing to the assigned LUT will be checked as usual, including any combinatorial outputs your block has on that path. This is what you want when inspecting the complexity of the block, although during integration the actual destination could be much further away.
If you look at ChipPlanner you will find the submodule densely packed in the centre using virtual IO pins. If you route to physical pins, assuming there's enough, you will find the design stretched out like a spiders web as the fitter tries to meet timing (and most likely cannot). Since most of the IO will probably come through buses from dedicated hard PCS blocks from HSSI pads in IP cores, there's no point in fitting it to hard pins.
Update: What you might like to try is adding a design partition for your block, and setting up a logic lock region for that partition which is a small subsection of the whole chip. This will give you a little square of area that the core will have to meet timing within, with an unlimited number of interconnections coming out on the periphery. This will then give you timing analysis on the input/outputs to a strict boundary, which may be more realistic than arbitrary/favourably positioned Virtual pins LUTs.
Quartus help: def_virtual_pin