Hi Pieter,
For doing the ALTER TABLE DROP, do you have the database option "select into" set or are you using the "full logging for alter table" setting?
In general, I think you are probably right that much of the growth in the log has to do with the compiled objects. The ALTER TABLE would mark those objects to be renormalized (and thus then recompiled) the first time they are executed. The compilation (creation of a new query plan in procedure cache) does not grow the log, but the renormalization does rewrite the query tree stored in sysprocedures, which involves (on a 2k page size server, anyway) about 2K of log for each row in sysprocedures for the object. There can be a surprising number of such rows, something as simple as "create procedure p select c1, c2 from t1" produces 7 rows.
(sysprocedures rows are wider than they look, they have a hidden column that contains the query tree in binary form).
These log records would be generated as each object is executed for the first time after the alter, so that probably generates a lot of activity very quickly, then trails off.
Each of these would be separate transactions, so it should be generally possible to do a DUMP TRANSACTION to truncate the log after the ALTER (and perhaps some of the more immediate activity) has finished.
Here is a little demonstration: