As of IIS 7, few/none I can think of. WAS doesn't load optional components, it just does its thing.
IIS 6 hosts an in-memory copy of its configuration from/for/in the Metabase, in InetInfo.exe. If that gets jammed up, everything fails (usually all at once), and that'd require a service restart (IISRESET /NOFORCE if possible).
99% of the time, it's enough to recycle an App Pool to restore service, or to get a particularly recalcitrant application to reread its configuration (if it's handle-leaked its way out of file change notifications, or it's bored with life, or just hanging). IIS 6+'s Worker Process Isolation (Mode) means that most failures are constrained to a single process, and a recycle will typically work, starting a new worker process on the next request.
There are exceptions, as with anything, but as a rule of thumb for "pure" web apps, that's all you need to do.
COM apps, apps that use state outside the web server process itself, and so on, might be more troublesome, and some apps won't support multiple instances of themselves (the one shutting down hangs the one booting up) in which case you're a bit stuffed, but on the whole... works.
IIS7 doesn't host an in-memory copy of anything, and the processes involved know how to read a configuration file directly.
WAS (Windows Process Activation Service) reads config files, carves them up for App Pools (see: Inetpub\Temp\AppPools) and lets the worker process read their own configuration. I haven't seen many situations in which this got broken enough to require a restart.
InetInfo doesn't need to exist in IIS 7 for a working server, unlike IIS <=6 - it's purely there for compatibility with apps that need to talk to a metabase emulator (Admin Base Objects, ADSI, legacy IIS 6 WMI, that sort of stuff).
As for when to restart the service:
- Very rarely
- When WAS is logging errors that read like it doesn't want to live
- When everything is falling in a heap all at once (and individual app pools can't be identified to be recycled
But otherwise, just recycling the App Pool is usually enough to recover.
See also another answer in a similar vein (yeah, mine as well):
Steps you pass trying to resolve irresponsiveness of IIS web site