Using GetSizes for this isn't going to work well. If the command object is not tied to a particular folder tab (as in the script currently), then it will end up picking the active tab/window and the results of the size calculation may be sent to and update the wrong file display entirely. If you start refreshing the column, then click on other windows, the size column stops populating in the window you expected it to calculate in.
While you can fix that using cmd.SetSourceTab, you then start to see progress dialogs while the sizes are calculated, which you would not want from a column. I don't think there is a way to suppress those currently.
The other issues can be solved by getting the information from the file display, but you either have a choice of unwanted progress dialogs or a fragile column that breaks if the tab becomes inactive.
Better to not use GetSizes here at all, and calculate the sizes in the script. This is easily done by recursing through the folders, which is easily done using the FSUtil.ReadDir method we provide for doing that. Examples of how to do that were in the script you used as a starting point. That script recurses the folders to calculate the file with the newest date, but the logic is similar if you want to add up all the file sizes.
It'd also make sense to count the files in the script in the same way, which makes sure the sizes and counts were calculated consistently. Also allows you to build in logic later which skips some folders or files (e.g. backups).
Note that we provide a FileSize object which handles 64-bit sizes and basic arithmetic. It's best to use that rather than a normal scripting language variable, as the scripting languages tend to have smaller limits on their integers.