2 Jimmy
Тут вопрос в другом, для чего это нужно.
Если нужен веб аксес по протоколу HTTP, то так.
Если нужен юзер интерфейс, то ваш список не полон.

Можно ещё использовать технологию DHTML, технологию XML.
Я лично вообще использую в VB компонент WebBrowser, который открывает локальные файлы, сформированные программой.

Вопрос был, для чего это нужно HighMan.

Тонкий клиент всем хорош, кроме случаев, когда на нём надо сделать что то отличное от отображения информации.
Тонкий клиент просто необходим для веб приложений.
Но! для интрасети важно прежде всего удобство пользователей, а не желания сисадмина чего-либо администрить. Поэтому желательно иметь клиента потолще.

-- IE - тонкий клиент, вся бизнес-логика сконцентрирована на сервере
Это принцип любой клиент серверной системы, IE здесь не причём. А вот логику отображения и передачи информации реализовывать должен клиент.

-- к железу клиента требования минимальны
То есть используется оно просто как терминал, процентов на 5 своих возможностей. И кстати не таки уж минимальные требования у IE (откройте таск манагер посмотрите в мем усадж).

-- не требует инсталляции и конфигурирования
Кроме установки самого IE последней модели и настройки его сеттингов.

-- приложение легко масштабируется (в плане количества клиентов)
Полностью согласен, а всегда ли это необходимо?

-- если WWW поддержка использует только стандартный HTML, то обеспечивается платформенная независимость(MSIE на Windows, Netscape & Opera - other OS).
Здесь тонкий клиент впереди планеты всей. Однако из-за существенных различий в реализации единого стандарта HTML разными браузерами, такие вещи ведут лишь к неоправданным затратам на разработку. А вот платформенно независимых веб серверов, удобных для разработки веб приложений я не знаю. Наше корпоративное начальство, например, решило, что теперь все внутренние сайты должны быть на лотусе, а IIS-ы все должны быть прикрыты. И что мне теперь весь ASP на JSP переписывать?

-- апгрейды приложения прозрачны для пользователя и управляемы.
Апгрейды всегда туманны для пользователя, а если это происходит в момент его работы, то могут вызвать ещё и недоумение. Поэтому политику апгрейдов надо реализовывать как то более продвинуто.

-- априори поддерживается удаленый (географически) доступ к БД
Прям уж так и априори! Если вы имеете ввиду интернет, то необходима настройка файрволов, а как же мерзкие хакеры? Если же локальную сеть, то дотаточно TCP\IP.

Но, при определенных условиях, такой подход может себя с лихвой оправдать.
Плата за использование веб технологий в интрасети - неоправданное повышение сетевого трафика (данные качаются вместе с формой), усложнению связи с локальными ресурсами клиентского PC, такими как файлы, реестр, другие приложения, усложнению механизма обращений к серверу.
Преимущество лишь одно - доступ к данным через прослойку с ограниченной функциональностью, под названием веб сервер. То есть вместо порта 1433, через который хакеры могут сделать с вашими SQL сервером всё что угодно, вы имеете на файрволе порт 80, через который можно только качать HTML.
Поэтому оправдать себя такой подход может только для веб приложений.

DHTML - объектная модель документа в броузере, которая позволяет управлять документом именно в броузере, а не на сервере, что исключает автоматически ее расмотрение, как инструмента для client-server приложения. Только в качестве "оживления" пользовательского интерфейса.
Позвольте с вами не согласиться, очень даже легко, если в качестве сервера рассматривать не IIS а SQL. Более того, я даже видел приложения написанные в виде HTA. Многие недостатки тонкого клиента такой подход уже решает, сетевой трафик уменьшается, обращения к серверу упрощяются. Но это ещё не идеал.

Правда, как всегда, где-то посередине. Комбинировать надо подходы.