Can you be more specific about the use case?
There is at least one scenario where three things happen that would make Unix symlink support in Wine useful:
1. The application expects to be installed to the C drive, but its files are physically stored on a different drive, and copying them from that drive would take too long, so they are symlinked instead.
2. The application needs certain files to be completely replaced with different files from a specific language pack in order to change the user interface language. For example, there may be an "EN" directory with English-language files and an "ES" directory with Spanish-language files, and those files need to be moved or copied into the application's main directory.
3. The application is sometimes run on Windows and sometimes on Wine, including the script that moves or copies the language-specific files. Right now, if such a setup script is run on Wine, Wine is unaware of the fact that the language pack files are symlinks to files on another drive, so the `move` command makes deep copies of them, which is slow. When the same script is run on Windows, `move` just moves the symlinks themselves instead of copying the file contents over from the other drive. (Or the script could use `xcopy /B` to copy the symlinks instead of moving them, but that doesn't work at all on current Wine.)
It’s also worth noting that the Linux ntfs3 driver exposes Windows symlinks as if they were Unix symlinks. I think the fact that the symlinks might have been created by Windows on an NTFS volume is a good argument for continuing to treat them as symlinks in Wine.