We ran into this issue as well, but our primary problem was the incredibly poor performance when the user performed client-side actions such as sorting or filtering (even after installing the July hotfix). Using the research by the original poster regarding the increase in performance when the table did not contain a colgroup element, we devised a workaround that causes a slight delay on the initial load, but resolves all other performance issues, including situations where the grid is contained in an Ajax update panel.

The basic approach is to save the colgroup element in the table, remove it, ask the grid to generate all row ids, then restore the colgroup element. Executing this code at the end of igtbl_initGrid handles all scenarios that we have tested. For those that are interested, here is the code that we used to work around the problem:

function InitializeGridIds(oGrid) {
    try {
        var oChild = oGrid.Element.childNodes[0];
        try {
            oGrid.Element.removeChild(oChild);

            for (var nI = 0; nI < oGrid.Rows.length; nI++) {
                var oRow = oGrid.Rows.getRow(nI);
            }
        } finally {
            oGrid.Element.insertBefore(oChild, oGrid.Element.childNodes[0]);
        }
    } catch (ex) {
        alert(ex.message);
    }
}

We modified the end of igtbl_initGrid as follows:

    igtbl_getElementById(grid.ClientID).control = grid;

    // Ensure the grid ids are properly initialized
    InitializeGridIds(grid);

    return grid;