windows server sharing printers, why does local machine need driver?

You've answered this yourself with your CUPS server accepting everything as PostScript.

Each printer has different features, capabilities and support which is why different printers require different drivers. Remember, Postscript and PCL aren't mandatory.

It's easily circumvented when discussing text and a simple B&W laser printer, but take it to the extreme. You have a 50 page booklet in MS Word and you want to print to a big complicated multi function printer. Firstly, where would you configure Duplexing, which tray to get the paper from? These options come from the print driver - so is the print server expected to interpret the options and display it to the client somehow?

Secondly, when you click print, what exactly is MS Word meant to do with this document? Send it as a raw document - imagine the processing overhead? Or maybe MS could develop a custom universal driver - entirely possible, but it's unlikely to support complex features nor have any guaranteed success.

One of the appeals of a print server is that you can send it a file, and have the processing done on the print server, rather than at your local machine

I'd say this is untrue anyway. Print servers are about centralised management and distribution, not about offloading work.

Have you considered simply adding a different basic 64bit postrscript driver on the print server? This would probably get you the same result as the CUPS solution, with less mess.

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.