"There are some gotchas in terms of p/invoke calls not always working across 32/64, as well as Managed DirectX not working well under 64-bit, but on the whole I think its something people are going to be doing more as time goes by."
This is caused, in .net, by having the AnyCPU flag set. AnyCPU on an x64 machine will run the process as a x64 process, which proceeds to explode when attempting to call/load a 32 bit dll. Since those libraries are 32 bit you need to set the build to x86, to ensure the app will run as an x86 process, if on an x64 machine it will run in WoW.
Signed Drivers. No more "Unknown Device Driver" blue screens, drivers that cause issues are found out, and rightly blamed for their crashes.
Signed drivers also means the drivers are current. Manufacturers that used to get away with updating a driver once every 2-3 years had to get signed/certified. Which means the driver is relatively current and had to pass basic "is this total crap" test at Microsoft.
This "lack of driver support" I've always seen as a boon. Forcing manufacturer certification.
More address space. Others have mentioned that this allows more RAM, which is true. But it has more impact on memory management performance. It also means having 4 gigs RAM and a graphics card with 512MB on it will be fully used by the system. On a 32 bit OS the system has to decide, out of the limited addresses, what hardware gets what range, physical RAM loses.
Then there is always the possibility of using more than 4 gigs RAM, good for when you have lots of VMs
x64 Vista loads core OS processes/services, during boot, into random addresses. Giving some exploits a 1/256 chance of picking the right memory location, instead of 100% on a 32 machine.
No kernel patching. None. Nada. Zilch. It does mean some Sysinternal tools do not work, however it means xyz spyware/virus cant maliciously apply the same techniques as sysinternals to hide forever, intercept calls, etc. (this is what keeps out some anti-virus software... as well as viruses)