Table Space not being freed up after large DELETEs
There is a memory leak when dealing with heaps (no clustered index).  Multiple deletes/updates causes space to be "lost".  It can easily be fixed by either adding a clustered index or rebuilding the table.

ALTER TABLE tablename REBUILD


However in this case the table is stated as having a clustered index and the same problems don't apply.  Using Occam's Razor I'm going to guess that this is because of the varchar(max) column that was added.  Remember that when you add a varchar column very little space is added to each row until data is actually added to the column.  So in this case my guess is that as the varchar(max) column has been filled in the table size has grown.

Also remember that this table is a running year.  That means that when the column was added presumably it wasn't filled in for any of the old rows.  As the year goes by and old records are dropped off and new records come in a higher and higher percentage of the rows will have that column filled.  Not to mention the possibility of additional information being added over time.  (New comments, additional requirements when putting data in the column, whatever).  This means that the table will grow over time, but should stabilize somewhat.

A very easy way to check the size of a table is to use the system stored procedure sp_spaceused.

 -- Using msdb.dbo.backupset as an example
 exec sp_spaceused 'backupset' 

name        rows        reserved    data    index_size  unused
backupset   14793       13072 KB    9112 KB 1640 KB     2320 KB


Note how we are given the number of rows, the total size of the table, how much is used for data and how much for the index.  And in this particular case most importantly how much is unused.

Every table is going to have some unused space, but if you start seeing that number climb then that would be a warning sign.  I've never seen it happen on a non-heap but of course I haven't seen everything either.