For the last three years, I have been writing intranet applications for use in corporate environments. An intranet application uses the same technologies (TCP/IP, HTTP) that are used to build web applications for public consumption on the Internet, but it is only accessible from within the company. I am now wondering if there is still much merit to this development model (as opposed to client-server software) when web applications stop being simple query and reporting screens, and pile on a richer set of functionality (and a hairier set of complexities).

Ease of deployment: One big advantage that is always attributed to web-based applications is the ease with which they can be deployed, maintained and upgraded. Since there is nothing to install on the client-side (you only need a web browser), you just install a couple of web and database servers in a central location. Contrast this to having to roll out a new version of the client application to hundreds of workstations.
I believe that this contrast is not very stark anymore: You can install local applications with a few clicks from the web browser, and applications can also update themselves automatically over the network.

No data stored on the workstation: Because all data resides on the central server, users become independent from individual workstations (they can be productive from a co-worker's desk, from their home PC, or from the hotel's business centre), and it is easier for the company to protect the data, both in the sense of keeping backups and in the sense of preventing unauthorised access (no more lost laptops with customer records). There is nothing however that prevents local applications to work in exactly the same way by just having the program itself on the workstation and loading data over the network. Client-server applications, in fact, have always worked this way.
There are big advantages of having at least a subset of the data locally available as a working copy, most notably the ability to work offline and less time spent waiting for data to load. One of the newer directions in web application development is browser-local storage, to enable exactly this feature.

Rich Intranet Applications: Before the client-server architecture, applications used to be accessed from dumb terminals, that were basically just a monitor and a keyboard, with no local computing or storage capabilities. The application itself would run on a big mainframe, which would have to handle everything down to interpreting keystrokes and redrawing the screens. In a way, traditional web-applications work like that, too: The web server creates HTML to render a page, the browser sends every click on a link and every submitted form back to the server, who in turn creates HTML for the next page.
To create a better user experience, so-called Rich Internet Applications use the scripting capabilities of modern browsers (JavaScript or Flash) to work more like client-server applications (with the client being downloaded afresh every time), in that instead of refreshing the whole page every time only the relevant pieces of data get transferred to and from the server.
So now you can have something in your browser window that looks and feels more like a client application. The first problem I have with going that way is that browsers were not designed for such usage and old-school web applications are already using ugly tricks to work around the inherent limitations of the platform. JavaScript RIA are really pushing it, and you need to have a pretty smart crew of hackers to make it all work. Otherwise it will be less usable than it was before. The second problem is that it blurs the lines, and whereas it was previously clear that some things cannot be done in a browser, everything seems up for grabs now, including things that still cannot be reasonably done in a browser.
The best RIA (like GMail) are not trying to replicate desktop applications exactly, but enhance the experience of something that still feels web-ish. There is a cultural gap between the Internet crowd and people who attach Word files to emails (and print them), and there are still different tools for different jobs. When you end up promising people that they can do everything they can in Word or Excel on the web now, you will be trying to fix formatting and printing and layout issues forever.

Cross-platform: Web applications can be accessed from Mac and Linux machines as well, and they continue to work after a Windows update. Again, for web applications done right, this may be the case, but there are so many subtle and poorly documented bugs and idiosyncrasies among browsers and browser versions that you need a pretty smart crew of hackers to make it all work. Especially when you go the RIA route. As a business software maker these technological details are probably not what you should spend your manpower on.
Client applications can be reasonably cross-platform as well. For business applications you may be fine with a Windows-only solution anyway, which thanks to C# and .NET should be much less painful than in the old days of DLL hell. Or you could use Java. Whatever development tools you use, writing client applications gives you much more (complete?) control over how your application is going to look and behave, a fact that should make any developer, tester, user manual author, or product manager happy.
Another thing about cross-platform applications is that in order to work equally well on many platforms they tend to ignore the more advanced features that set each of those platforms apart. So for a really extraordinary user experience you may need to focus on one platform. This is the reasoning behind most Mac-only software. On the other hand, when you are writing business software, the people that make the buying decision are not usually the people using the software, so you are probably not aiming for extraordinary user experience anyway.