That's a good question. The intent here is to invalidate caches.
One of the changes in 4.11 is that most of the comboboxes in the application now cache their data. If you watch the queries executed by version 4.10 and earlier, the exact same queries get run every time you open a window. In 4.11.0 and later, many of these queries are run once, possibly for the entire time the application is running. This leads to a measurable performance improvement in the application, especially over slow networks.
The triggers you mention allow any client that's listening to invalidate specific data. The string that is generated tells the listener exactly which table was changed. Thus if anyone anywhere edits the terms table, every client that has opened a window with a Terms combobox (Customer, Sales Order, Quote windows, for example), invalidates its cache of terms. It does not immediately requery. Instead, the client requeries the next time it opens a window with a Terms combobox.
The combobox queries are the first in a larger set of objects that will cache their own data. Other objects on the list are MetaSQL statements, the various "cluster" objects, and application scripts. That's why we created triggers to all of the tables. We don't know a priori which tables we're going to need to monitor. The end result is that overall application performance improved.
I hope this addresses your concerns.