We used both environments (we're a public school system), and when I started here we were running several terminal servers for teachers and students, and now we're fat clients and role-specific servers (no terminal servers for users).
Pros- centralized management. When you have two or three people overseeing a huge number of users with a significant portion online at any time, it is fantastic to be able to install a "necessary" desktop shortcut or install a program a few times and have it instantly available to all the users rather than rely on automated package installers or AD to hopefully roll out the change to desktops. I know people talk about how wonderful AD is at installing MSI's, or how XYZ can solve this installation issue, but we've had plenty of cases where for one reason or another the installation failed or didn't work properly and we had to clean up the mess by hand or just install the @#$ thing manually at each workstation. Not. Fun.
"Instant" troubleshooting. We were able to check a user's session easily and quickly when a call came in. Yes, remote desktop software can do this (and we use it). But on the terminal servers, you have a small pool of machines, not a desktop that was tweaked or altered with XYZ programs that you didn't know where changed by another tech or it was changed and the records are lost or never kept. Tight adherence to policies and record keeping can do this. Reality is, at least in public school systems I know of, this isn't followed very often.
You have fewer machines to back up and monitor. Desktops are easily swapped and can be run on the cheap. All you need is a thin client or a system capable of running terminal service client; hardly need a gig of ram and a hundred gig hard drive for that. We were running PII and PIII systems with barely enough RAM to run Windows 98 comfortably as clients; students were sticking gum in them and jamming them with papers and when the time came that the client died, we just swapped it out with another cheap spare, no special software or custom configuration necessary.
Monitoring users was simpler. Not really big brother monitoring (unless you wanted to take it to extreme), but when users were suspected of violating the AUP or their sessions were showing unusual activity, it was easy to pop in and check what was happening (running an exe you're not supposed to? Why is the web filter showing odd activity for your session here? Sometimes it was just a call from a teacher saying Johnny was acting suspicious and minimizing something while in class)
Upgrade a server and a large number of users benefit, all at once!
Cons? You have twenty users on a system. System reboots, dies, hardware issue,...twenty users, kicked offline, instantly. And users don't understand terminals to begin with. They don't care why something's weird. They just know something isn't working. One switch goes wonky or one server goes wonky and you've taken out a large number of users.
Load balancing creates issues. If user is on machine A, and machine A (or network connection to A) goes down, they may log in and get machine B. Their session was still on A, and they wonder why they now don't have their Word document they were working on, but it's in their home directory and it's showing up as "open" or "locked." Whoops.
Resource hogging. Can be handled with quota management on resources, but we had cases in early versions (Win2k term services) where a user would log in, load animated maps from weather sites, and leave for a class without logging out. Half an hour later the machine is CRAWWWWWLING. Memory was leaked from the @#% flash movie animation, hogging RAM and leaving us with no choice but to kill the session.
Some programs do NOT like terminal services. Hopefully it improved, but a big one was Office. You had to install it with a special "terminal services mode", or the installation would act really weird or not function properly. Other programs just acted strange. Windows was NOT designed to act as a multiuser platform; it was meant to support multiple users asynchronously at a workstation (this workstation allows any number of users to use it at different times), unlike UNIX workstations that have their design roots in timeshare systems (a workstation you're sitting at can be running with another ten or fifteen users using SSH or remote X terms and you'd barely be aware of it unless they were hogging a resource). This could easily get to be a technoreligious argument, but the fact is that because of the "organic growth" in Windows' architecture, there are many developers that take shortcuts and older software simply acts...strange...under Windows Term services. I think that issue has definitely improved as MS has started forcing people to adhere to design recommendations.
Need to reboot a server or perform maintenance? Again, you have one machine going down, it takes everyone out.
You need a reliable network infrastructure to work. The users need a good path from desktop to the server. If the client machine died, a switch, a cable, a server,...their computer platform dies. With fat clients, you could potentially have a server failure and users could still do something else (i.e., mail server is down, but users can still work from their home directories or local files and just be irked that the mail server is down, not the whole system).
Most businesses wouldn't have to worry about it, but if you have cheap shovelware (think kid's "edutainment" titles), it doesn't take much to bring even a powerful server to its knees.
Printer drivers acted strange at times. Interaction among software increases the chance of "glitches". Especially with terminal servers...they always seemed more sensitive to it. But maybe I'm being paranoid. Remember one server affecting everyone? Well, one bad software install can cause headaches for everyone...and bit rot was a constant cause for edginess as drivers were updated or configuration changes were made.
There is a layer of complexity added. You brought up USB, maybe things like sound, etc...again, this I think was improved since our time. But it still means another place where things can go wrong, and it's not like sitting down at a fat client to troubleshoot. You're trying to redirect stuff over the network on a server that is dealing with connections from another dozen users. Weird stuff happens. In IT, complexity is bad to intentionally introduce.
Overall terminal services are cheaper, despite the CALs necessary for licensing. Your systems scattered around are cheaper, you can manage more users with fewer people, and you invest in your servers and network infrastructure, not necessarily giving the CEO a $2,000 machine for doing his email. But they're only cheaper if you're running in an environment that is suited for terminal services.
If your users are running Office apps, browsing the web, email...basic stuff...probably worth looking into. If they're running specialized stuff, test the @#$% out of it first, making sure it's compatible, that there aren't file locking or sharing issues or even display issues (print drivers were horrible at times if you did something that managed to get "printer monitors" running and they got confused to which display was actually being viewed, but it's not just those applications that hated the idea of multiuser hacks).
We had to move because over time we were getting more and more people that HAD to have something they wanted installed but other people didn't, and for licensing it could only be used by a small group of people. Or the software was made with Macromedia Director (ugh) and didn't "quite" work right (refresh was "off" with graphics, animations were choppy...). Or we had people running software that was just bloated and bogged down servers. Or we had people that had to use CD's for a presentation or material and they couldn't access them via the terminals (again, may have improved). Eventually we were putting in special workstations for certain tasks (log in once to run Photoshop, use the terminal shortcut to get to Office...) and finally it was too much of a burden to dual-support having labs that ran XYZ and terminals to support ABC. We had too many diverse needs.
That's my experience with them. They're great for certain tasks. You need to evaluate your client's needs and whether they're appropriate for that situation. If not, stick with fat clients.