The compaction is only relevant for bbolt database files, which are very common with lnd. In this case, the channel database is stored as a bbolt file named channel.db. Note that you can also use PostgreSQL with lnd to persist this information, in which case you don't need compaction (PostgreSQL has a concept named "vacuum" which can run in the background).
During operation of lnd changes (especially deletions) to the bbolt database cause gaps in the database file, which cannot easily be filled with new data. As such, after a while, the database file consumes lots of disk space, even though a fraction of it is just empty space inside the file. Deduplication/compression features of your filesystem might help to reduce the actual storage footprint.
When you trigger the compaction, a new database file is created and filled with the data from the original file by copying everything over. This way the actual information is identical, but gaps in the original file are skipped and do not consume space in the resulting file. This is somewhat similar to file system defragmentation from the Windows 9x (and before) era.
This compaction does not change (or interpret) the data in any way, i.e. no data is compressed or deleted. Every information persisted in the original database is copied over to the new database, bit by bit. The only difference is that the internal database structure changes, which you do not see from the outside (aside from the intended benefit of reducing the storage footprint of the file).
As compaction is bbolt specific, I don't think other implementations make use of this. In general all databases should already have some means of freeing up space of deleted data, and I guess that all node implementations delete most unnecessary information after a while.
