It's actually far more important if the "other" display happens to be onboard video, and you are using an add-in card. Sometimes, after upgrading to a standalone video, XP still loads the drivers and allows the onboard video to be "active" in the background.
Just some back-of-envelope calculations - assume a R9200SE card, 64-bit mem, 200Mhz DDR (400Mhz effective) clock. That gives you a total theoretical memory bandwidth of 8 x 400 = 3200MB/sec. Now lets assume you have both RAMDACs enabled (dual-head), and both are displaying 1024x768 @ 32bpp displays, at 75Hz. That's 1024x768x4x75 = 225MB/sec, per each display head, for a total of 450MB/sec / 3200MB/sec, or 14% of your card's memory bandwidth going for just display-refresh purposes. Disabling one of the displays/RAMDACs, would cut that overhead in half. Not to mention, that assumes "perfect" memory-access scheduling efficiency, which doesn't happen in the real world. Display refresh is the highest-priority task (otherwise you would get visual anomolies on-screen), and can interrupt/delay other tasks like GPU rendering and host CPU access to onboard video memory, so when you add overhead, that number is higher. I actually didn't think that it was so high, wow, but I did pick what is nearly the slowest card on the market for the example. For something a bit more modern and high-end, the numbers are probably closer to 1-3% like I said earlier.
Interestingly, also, when you consider that a 32-bit 33Mhz PCI bus has only a maximum theoretical bandwidth of ~128MB/sec, and a simple onboard video display will take nearly twice that amount of memory bandwidth, just to keep the screen refreshed, then you start to realize what sorts of overhead to the rest of the system (CPU/memory subsystem especially) the use of onboard video will cause, and why it is commonly so vehemently avoided.