Actually, it'll work either way -- the shell strips the quotes in the same way before launching the app. (A sad reflection of stupid UNIX shell tricks..)
In this particular case that is true however while in this case it may be true and mostly because dd is one Unix program that doesn't conform to the norm when it come to its arguments in that it parses the command line regardless of the order of it arguments as well as I don't think the shell is validating dd arguments in the same manner as it does other Unix programs. I could point out may (if not almost all) instances where placing a single quote if front of a programs argument when referring to a parameter for that argument vs in front of the parameter of the argument that it will categorically fail but the point I'm trying to make is more from a programmatic coding standpoint in that it is better form to present commands for users to execute in a manner that is consistent with normal practices and not quirks and or bugs in a give program.
In that context I take "dd 'if=Windows Vista-s009.vmdk' of=/dev/null" to not conform to normal standards and would rather present a user with a command line that represent the normal standard of quoting only the file's name and or fully qualified pathname or just escaping the spaces in a file's name and or fully qualified pathname with backslashes both of which are normal standard practices vs using a quirk or bug.
But in any case, the hope is that this might be a way to check if the file data itself is readable from disk, to see if the problem is there or in the VMware structures ...
I totally agree and I have found it (dd) quite useful when normal copy and or disk imaging methods fail as well as when there is actually a bad sector within the sectors the file actually occupies and being able to recover the file in part and or whole where all other methods failed. I remember one trim trying to recover the users outlook.pst file on a Windows system and nothing Windows based could recover this file and all DOS/Windows based methods reported bad sectors in the space the outlook.pst file occupied. I booted the system with a Knoppix CD and used dd to copy the file across the network and was able to open the file then in Outlook. I tested the database and if had a few nonfatal errors that it cleaned up. The user was lucky because he hadn't backed it up in over 6 months but thanks to dd and my persistence he lost nothing.