The problem is governance. The web sever needs to be patched, the web site configuration needs to be maintained, as does the web application. Bear in mind that a display doesn't live in an IT department, and that developers don't maintain apps - operations does. So if you compare the web server/web site scenario to a single, self-configuring native app (presumably a single .exe and a couple .dlls or something, the .exe is cheaper over a 3 or 5 year lifespan, especially if the .exe works with SCCM and ops can push updates out using WSUS or similar.
I guess if you're into Windows, setting up a web server actually _is_ a hassle to you. Rest assured that there are easier ways. If you simply want to use a web server for local sharing, forget about patching and "maintaining" the configuration. Just install it and you're done (or why not use the file:// URI scheme? I can't see any compelling reason not to in a non-interactive setup). As for maintaining the web application, well, only in the same sense you have to maintain your .NET application.
Also, pulling numbers out of nowhere isn't going to help your argument.
If anyone I oversee actively decides to not patch and maintain a system within an enterprise network for any reason, they will find themselves back on helpdesk doing password resets until they learn better. Pentesters / hackers love using setups like you suggest as easy targets to provide them with perstitant backdoors.
3 and 5 years are the common life cycle's enterprise IT use when discussing any existing implementation or any new system design. These are not pulled from nowhere.
First off, when I say "maintaining" I meant the configuration. When I say patching, I mean patching, not just trivially installing software updates. Spearchucker was trying to make this a look like a huge disadvantage over maintaining a Windows system, which it obviously is not.
Oh and as far as I'm concerned "3 to 5 years" is still pulled out of nowhere. You aren't mentioning any sources, just describing a really vague process that you think is "common". If you have a working, flexible system with which you can harness a huge continuous effort in developing the technology behind it for free, you aren't going to kill it off just because your enterprise clock says so.
