FavnИ кто мешает сокетному серверу работать с БД? Такая "сетевая прога" с работой с БД пишется за день на J2EE с готовым JMS. Или дня за 3 на C++ с сокетами, например. Ладно, с отладкой и мультитредингом - за неделю. И дергается из БД через UDF из SQL и/или таблицы с очередями сообщений.
Клиент - еще тупее, а в случае JMS - просто стандартный.
Как это кто мешает? Мы же должны смотреть на это как на заплатки, если есть фича? Так мож и другие доделки к СУБД привистовывать? Мы же хотим чтобы СУБД как можно больше делало для чего в плане управления данными. Я думаю, что это проще, наждежнее меньше неопределенностей.

FavnА я думаю, что такие функции логичнее выносить на middleware в трехзвенке, чем нагружать сервер БД "внешними" для него функциями, в т.ч. и с точки зрения экономии денег на лицензиях. А оповещение о чем-то пользователя в отсутствие коннекта к БД - функция явно внешняя. Как и отправка почты, SMS и т.д.
Но холивар 2 звена против 3 затевать не будем.
Скорей всего, эти предположения не могут полностью отменить пользы данной фичи СУБД: произошло изменение данных в БД, достойное оповещения пользователся, при этом коннект не нужен. Поддерживаются возможности строить разные модели оповещения на уровне БД: на тетьем уровне. Проектировщик занимается именно логикой работы с данными, а не физикой типа написания сокетов. Я не говорю что это нужно очень часто, но обращаю внимание именно на само наличие такой фичи, что дает надежды, что в случае чего найдется и для других ситуаций фичи.