To expand on the point(s) above:

• with a web interface you get a client/server architecture out of the box
• a large (if not complete) portion of your user base is going to have the client portion installed already
• conceptually a web / CGI model (here's a request, do something with this stuff, send me back a response) may be easier for many to get their head around, as opposed to event driven GUI programming which requires a different mindset
• coincidentally since many current "programmers" are familiar with the CGI model, it looks like the appropriate hammer for whatever nails they see
• pure supposition on my part here: non-technical people may be more inclined to pick up on using a web interface ("Oh, it's just another browser form") versus learning to use yet another custom application ("Where's the menu item to turn off that annoying paperclip; I hate those things. What do you mean it doesn't have a talking paperclip? All my other applications annoy me with one. This program is terrible! I mean come on, where's the paperclip?")

Update: More thought(s).

• Web interfaces are amenable to separating the application from its interface; 4 months down the road when the marketing department decides to rebrand and your app should now use the colors puce and taupe everywhere to match the corporate identity it's much easier to let J Random Designer update his CSS and not involve any real developers or have to make changes in code (granted with Tk you can do it to some degree with resource defaults, but not to the extent that you can completely rearrange a web page with CSS and/or structural changes to HTML templates that are orthogonal to the back end application logic)
• Related to the client/server remark above, with attention paid to standards and the browsers that ignore them (*cough*IE*cough*) you can get a very wide array of client OSen upon which your app is usable from