If you do it infrequently, it won't kill the SSD, at least anytime soon. But that act of doing it, even on a VM, is pretty much pointless. Assuming that the virtual filesystem is not passthrough and configured as a single contiguous file, then the only difference is that the VM would be reading/writing to/from a single file instead of many files. The underlying hardware still has to seek within that file just like any other file on the host filesystem. On an SSD, whether that file is physically contiguous (i.e. defragmented) or not means nothing to the SSD. All requests for data by the host get translated into hardware commands for the SSD controller. At that point, the controller doesn't know or care what a file or filesystem is. It just goes and fetches the data.
You are in theory correct. This would depend entirely on the configuration of the VM host. Since you can choose if the virtual drive will identify as a hdd or ssd in the settings (at least this has been the case with all the host setups I have used before). But like you said, if this is a modern Windows, the defrag client will say optimise for ssd and defrag for hdd.
To add my answer to the pile; I would optimise the host os and leave the guest os alone, OP. No need to run the defrag in the Windows VM. The virtual drive is stored on a ssd so access times are good even if the virtual drive looks fragmented inside the VM.
Hello ChRoNo16! Seagate here. SSD’s by their very nature don't have a file structure as they are a group of flash memories. Defragmenting an SSD will just shorten the drive's lifespan and does not have an effect on its performance. There is an optimization technique that replaces defragmentation which is called TRIM Command. You can read more about it at here.