Which is a totally bass-ackward way to engineer anything. How on Bob's green earth does it make sense to have a lame, powerless server that requires hundreds of beefy clients? Servers are easy to manage, clients are hard. Clients are heterogenous, servers are exactly what you want them to be, and stay that way for every visitor unless you decide to change them. The thinner the client, the happier I am, both as a developer and as a user.
As a developer, the less stuff I do client side the more confident I can be that the API I want to use actually exists. As a user, the thinner the client, the more likely I can use it on my three year old PDA that I don't want to replace, or my eleven year old laptop, or the public machine at the library that hasn't been updated since the last time someone had time to write a grant, or the internet cafe in Darkest Peru.
As for developing internal apps for IE - can you say "proprietary lock-in"? I can, and it's a reason why I'll never be able to reccomend in good conscience that my employer develop for IE. (Or any other closed, single-vendor technology.) If you have to re-write all your essential internally developed tools just to switch to another vendor, then your current vendor owns you. Unless you're such a huge customer that you own the vendor, too, that's not a good position to be in. There are just too many open, cross-platform tools available for that to make any sense.
Heck, how many places have you seen a group of users within an organization who all had to have *two* computers, one of which was suited for their real job, and one of which existed only because there were one or two internal tools that only ran on platform X? Right now, I'm such a user - to get my work done, I have one machine. To use one single app that I need at most once a day for two or three minutes, I have a second machine that still has to be licensed and maintained by our IT department as if I actually used it.