Since you added the note about practical examples to your question, I will give you some examples of services I have written for enterprise applications (you don't say if you are an enterprise applications programmer but my guess is that most C# VS2010 programmers are). I think you are looking for an idea of what developers that don't work for Microsoft might write.
A heartbeat monitor service that checked if other programs were still running (this might have worked as a scheduled task as well, but was implemented as a service).
A report writing service that worked through queues of report requests, ran the reports, and sent them to different printers depending on what printer was busy. This helped offload a fair amount of work from a legacy application and allowed the report running to be shared by multiple cheap boxes running the service.
It was implemented as a service so that it would run continuously, start automatically on a reboot, and be able to use the standard windows services interface to start, stop, pause, etc. Also, if it was a scheduled task it would need to initiate getting data from other programs or a persistent source (a queue, a file, a database) rather than being available for other program's to call (socket, pipe).
The server portion of a that client/server application was also implemented as a service so that it would restart on a reboot, etc. There was another project with an .exe that ran the same program not as a service, to make it easier to debug on development machines.
I hope that helps. The other answers are better general answers though, especially the idea that scheduled tasks are probably easier to write and administer for most purposes now.