Wine doesn't support most Windows security constructs, and instead relies on the underlying operating system for security. Unless you run Wine as root, for instance, it's hard for malicious software in Wine to modify files belonging to other users. But Wine doesn't protect you against malware you run yourself.
End of story.
Except... there are a few weak things you can do to slightly protect yourself.
One can run each window app in its own bottle, and remove and disable executables that its app doesn't need (e.g. once you've set up a bottle, it probably doesn't need winecfg anymore).
"winetricks sandbox" removes the Z:\ mapping and the symlinks to $HOME... at least until you install ie6 or something that triggers a simulated windows reboot.
One can run clamscan or another antivirus package on Windows binaries manually before running them in Wine.
One can disable the workaround for the PreloaderPageZeroProblem, as long as you don't need to run DOS apps.
Distributions can also prevent the unintentional running of applications by requiring the user to explicitly say they want to open something with Wine (and not have it be the default action on, say, download via Firefox or Evolution)
One can change what Wine considers to be Z: via winecfg. Winefile will still navigate from '/', but trying to open anything outside of your new Z: drive will result in 'File Not Found." This trick only works if a malware developer isn't anticipating this.
One can run wine apps as a separate user. (Recipe, anyone?)
One can run wine inside a chroot jail. (Recipe, anyone?)
Harder, attractive, yet futile measures
It's probably possible to modify wineserver to disallow windows apps from doing any networking (unless they use linux system calls directly).
It's probably possible to modify kernel32 to disable executing linux apps from inside windows apps (unless they use linux system calls directly).
How can we prevent the c:/user/foo symlinks from being recreated on a simulated reboot?
I know of no way to prevent win32 malware from issuing linux system calls directly.
One could potentially scan PE modules when loading them to detect and disallow system calls, but it might be hard to enumerate all the ways to call system calls (int 80, sysenter, call ffffef00, call *%gs:0x10, etc.), and there might be lots of false positives. However, dynamic code generation or code packing methods easily defeat this.
One could ask the kernel guys to add a "no syscalls from this VMA" option to mprotect, but that's not likely to go over too well.
ZeroWine (Wine running in a virtual machine specifically to analyze malware)
http://blog.opensourcenerd.com/i-can-haz-virus (A nice illustration of how to get infected with malware in wine. Sadly, he perpetuates the myth that uninstalling wine will remove installed apps/malware.)