Yes, you could. I find it good practice to do a virtual clock when it explains what's going on. (About the only time I don't use a virtual clock is when the FPGA sends a clock off chip, which uses a generated clock on the output port).
What you have gets the same analysis. The only true difference is that derive_clock_uncertainty will derive different uncertainties between a virtual/external clock and internal clock. Right now it derives uncertainty to the same clock, which will be less. It's probably going to be a 10ps difference, but true.
I like the virtual clock for multiple reasons. You can use it as a tag for report_timing, i.e.:
report_timing -setup/-hold -from ext_clk...
Will report timing on all of these input paths, without having to describe the ports. It's not a big deal here since the inputs are a bus, but on interfaces with 20 different port names, it helps.
It also makes sense when looking through timing reports. As soon as I see a launch or latch clock with ext in the name, I know I'm dealing with I/O. Finally, you can do things to the external clock. For example, you can phase-shift it. You can apply set_clock_latency. Although we're not doing any of that, we can.