If you’re committed to making the change to MAC, then I say go for it. I personally don’t care for the MAC, but I will candidly say that most of that is probably due to unfamiliarity rather than anything inherent in the MAC system. As such, my views are just that - my subjective views - and thus have little bearing on your situation.
I also know that unfamiliarity affects people switching from WinXP - or WinVista - to Win7, because I just bought my wife a new laptop with Win7 and it took me a while to figure out where things were.
As for Win7 versus WinXP: there the unfamiliarity aspect definitely kicks in. Win7 is as alien, if you will, to WinXP as Mac OS X is, in many respects. That being said, as much as Microsoft’s OS engineers deserve to be roundly kicked in the pants on a regular basis, even they manage to learn from experience, and they have learned a thing or two from the security holes in WinXP.
Also, in terms of performance (i.e., speed, which is what most folks look for), I would keep in mind that a lot of what slows an OS down are the hardware drivers, and Microsoft has only some control over what goes into coding a driver. Also, here, unfamiliarity can cause problems; the APIs and driver hooks for WinXP are well-known (comparatively) and the writers of driver software are comfortable with writing for XP and have honed most of the inefficiencies out of their code. The same does not apply to Win7, which has made a lot of changes that affect drivers and driver code writers. That means that there will be a lot more inefficiency in the driver software until the code writers get more comfortable with the new APIs and the new relationship of drivers to OS in the Win7 code base.
Also, WinXP was much more tolerant of poorly written driver code than Win7, or even Vista, is. That means that WinXP is less likely to have a fit over a poorly written driver and therefore won’t appear to lock up when Win7 and Vista would lock up. However, that flexibility is a two-edged sword, because the same “flexibility” that allows WinXP to tolerate poorly written drivers is an open invitation for malware writers to write exploits that use that “flexibility” to get into the system.
It is not purely coincidental that one of the major ways of taking over a system is to shim your own driver in between two legitimate drivers in the driver stack (basically, there are several layers of code between the user experience - the user interface - and the cold, hard physical stuff, and there generally has to be a driver - a translator if you will - between each layer). So long as your ersatz driver passes the usual traffic up and down the driver stack, it can do lots of other things that you really don’t want it to be doing. In addition, it can mess with the traffic passing up and down the driver stack; without a secure auditing system, that messing around is almost impossible to detect (even with an auditing system it can be hard to detect).
Thus, precisely because WinXP is more “flexible” and will tolerate a lot more misbehaviour from drivers, it is much easier to insert a driver into WinXP that can engage in a lot of evil activity that WinXP will simply ignore as being just more driver misbehaviour.
Putting those two together, it is entirely possible that if you just take, e.g., the printer you have that worked fine on WinXP and plug it into a Win7 box, that printer will give Win7 indigestion until you get the correct, updated drivers from the manufacturer - unfortunately, many hardware makers don’t make their updated drivers automatically available, so you have to go looking for them, and even worse, many of them won’t support even not-so-old equipment and won’t, for example, write a new Win7 driver to accomodate a three-year-old piece of equipment. While that is truly annoying, it is more the fault of the hardware maker than it is of Microsoft.
Lastly, if you do have access to a good sandbox or virtual machine software, that could very well give you the environment you need to run a virtual install of WinXP as needed (Win7 might not sandbox as easily until the virtual machine writers get up to speed on it). Provided you’re running a good, robust virtual machine, I rather seriously doubt if anything you might catch with the XP install would carry over to your native MAC installation.
It is theoretically possible to write stuff like that - there are malware writers out there who are good enough that their code can determine if it’s running in a virtual environment - typically used to reverse-engineer the malware - and to alter its behaviour accordingly; however, as a practical reality you are almost certainly never going to run into something like that. It would require a malware writer who was good enough to write code that could detect that it’s being run on a virtual machine and be able to break out of that machine, and who wrote code to specifically attack a MAC OS X system running that virtual machine.
If you think that your odds of getting attacked by malware with that combination of features are high, then you’d probably be better off investing your money in lottery tickets, because the odds of winning the lottery are better than being attacked by malware with that combination of features.
At any rate, my apologies for the much-too-long saga. I would say again that if you’re committed to going the MAC route, you should go for it whole-hog - no half-measures: read up on it, get to know what it’s strong points and weaknesses are, learn how to use it securely, and learn as much as you can about what makes it tick. Think of it this way, it’s analogous to deciding to switch from an automatic transmission to a stick-shift: there’s no real point in doing that unless you’re willing to learn things like down-shifting.