In some cases, this change to noncached I/O made file copies slower. One of the situations Russinovich identifies is when there are real-time virus and/or spyware scanners in use. Reading or writing any file often triggers a flurry of activity by these programs; noncached I/O creates a further bottleneck as these programs vie to take a look at the copied bytes.
Other times, Vista's reduced performance was more perceived than real. When the I/O is cached, as it is on XP, the copy dialog may go away before the last of the file is actually written to disk. In Vista, the copy dialog stays up until the last byte is written, which gives the user the impression that the copy operation was slower.
Starting with Vista SP1, Microsoft has returned to using cached I/O for file copies when the files are on the local system. There are some downsides to this in certain situations, as Russinovich details in his blog post, but on balance it will probably give users the copy performance they have come to expect on XP systems.
I would love to see Microsoft provide this kind of detail more often about bugs and fixes. It is easier to have more sympathy for Microsoft's design choices when you can see the reasoning behind changes that initially seem to create more hassles than they fix.