I know this doesn't answer your question completely, but I would like to share my experience.
I have a windows console application that when scheduled is calling WCF services hosted in IIS. In this architecture the IIS is actually completely unnecessary and just an additional component to the overall solution. It was really included in the solution for marketing reasons, to beef up the product, and not for technical reasons.
These are the main problems I am facing, and why I would have avoided using IIS if I could for technical reasons, and this applies to my experience. Please note: I am not saying hosting WCF services in IIS is a bad idea. I am just giving my thoughts from the product I am working on at present.
- Having IIS in the loop means having another system in the overall solution. This in turn adds complexity to your deployment. Some clients have IIS6 others run 7. While these differences might seem small on the surface. Make no mistake, they're still different, meaning you're adding more potential for environment differences if you're deploying your product to different clients. DO NOT underestimate these differences. Ive even have clients trying to run my WCF services inside a SharePoint Site Collection (duh!) the point is A LOT more than you think can go wrong.
- IIS also has an AppPool consideration, which might need to be configured depending on the complexity of your product. That AppPool needs an identity to run under, adding more complexity again to your overall solution.
- I've had some issues where a single threaded service sometimes has "interesting" - Thread abort messages. While I'm still trying to figure out the exact cause, in the back of my mind I'm sincerely hoping this isn't somehow IIS related. The point is I wouldn't have this consideration if I eliminated IIS from the overall solution.
- I've heard discussions that IIS is a more robust hosting environment for WCF services vs self hosted. I am not entirely sure this holds any weight. If you know what you're doing there should be no reason for your self hosted service to be unreliable. But I guess it is more work upfront to implement some of the automatic features you get in IIS, for example WP recycling.
- I'm not overall dissatisfied with IIS in the loop, but its a pain when I hand the product over for deployment, and consultants without a strong technical background have to set up the IIS application. Usually something can and will go wrong, and involves someone with more technical experience to step in and solve. If you're self hosting you can much more easily package your app for deployment.
- Sorry to reiterate but if you go for IIS, you'll have 2 applications in your solution rather than 1, even though the business side of your organisation will only see the app as one business unit, essentially not understanding the full complexity of the solution you're implementing. For example: Why do we have 2 configuration files? Why do we have to configure mail twice? Why do we have to deploy DLLs to 2 locations. These questions get asked a lot.
- Lastly I thought I would mention if you're working remotely or over VPN to deploy to clients, the situation gets even worse, sometimes the consultant has access to sensitive areas you don't. As a developer try to eliminate as much extra baggage as possible from your overall solution. Lets also mention the sys admin might at times issue a convenient IIS reset, if your app is hosted alongside others, they'll reset your services.
Less systems in my experience = less can go wrong. But you need to decide if you have the skills to implement reliable self hosted services. This all in turn directly relates to the cost of development, deployment and maintenance.