The driver on the client pc basically transforms a print job into something the printer will understand - sometimes this may be something like PCL or PS, but in some cases it will be some more obscure only used by that brand/printer.
Basically the server just holds this prepared print job and queues them up before it can send it to the printer concerned. However the server also needs to know how to communicate with the printer, and it's handy to be able to print from the server, hence requiring the driver on the server.
One workaround I briefly looked into was setting up a 7x64 print server which seemed to do the trick, but the method I ended up using was to create images for the win7x64 pc's that already had all the print drivers in use in our organisation previously set up, so when deployed it needed to connect to a printer it already had the drivers.
Also I found a surprising amount of drivers successfully installed from server 2003/x86 servers to 7x64 clients, so the test 7x64 print server never actually went into production.
However these methods then end up with often mismatched driver versions on client and server which is not best practise at all, and using xp/x86 drivers on 7x64 also couldn't be considered best practise either, but this saved on upgrading loads of servers from 03 to 08 which at the time was the biggest reason to do so, so unfortunately I had to resort to those methods.
Also universal postscript drivers aren't always as good as you may hope - we had loads of HP business inkjet 2600's/2800's which weren't compatible with 7x64, tried using the HP universal ps driver which wouldn't work with them (I ensured to add a PS card to each printer before testing it).
+1 for built in drivers - I found some printers had no support for win7 on the manufacturer's website, yet Win 7 loaded a driver itself without issue.